Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create 2 options to decodeStrings without validateFileName #66

Closed
FabriceGaudin opened this issue Dec 13, 2017 · 5 comments
Closed

Create 2 options to decodeStrings without validateFileName #66

FabriceGaudin opened this issue Dec 13, 2017 · 5 comments

Comments

@FabriceGaudin
Copy link

FabriceGaudin commented Dec 13, 2017

Thank you for this lib, it works great !
In my use case, i'd like to ignore the "invalid characters in fileName" errors, to automatically convert backslashes to forward slashes.
I read that @thejoshwolfe recommands using decodeStrings: false here: #54 (comment)
But as he mentions it:

You'll have to do some extra work to do UTF-8 vs CP437 decoding

It's too bad to do this extra work whereas the lib can do it, and this work isn't directly linked to the validation step. I'd like to create 2 different options:

  • autoValidateFileName: default true, if false, the method validateFileName isn't called
  • decodeStrings: default true, if false, don't decode Buffer.

Or if my use case is not so specific, maybe we can add an option authorizeBackslash to avoid throwing an error in validateFileName.

What do you think about it ?

@thejoshwolfe
Copy link
Owner

Can you tell me what zipfile creator is putting backslash characters in filenames? I'd be much more willing to support that non-standard usecase if I can reproduce the problem.

@FabriceGaudin
Copy link
Author

@thejoshwolfe Unfortunately I don't know which zipfile creators are used. It seems that my users are getting zip files from a third party.

@thejoshwolfe
Copy link
Owner

I found a suggestion online that Microsoft .NET framework 4.5.0 until 4.6.1 had a bug where System.IO.Compression.ZipFile would not canonicalize the paths you passed into it.

I won't be able to test this myself for several weeks, but this may be the implementation (or one of them) that produced these malformed zipfiles we're all seeing floating around the internet. If I can get confirmation that we've found the culprit, I'll add an option to fix zipfiles while reading them (which will probably be enabled by default).

@thejoshwolfe
Copy link
Owner

thanks to @YanBeat in #88 for verifying that .NET 4.5 is indeed the culprit. Expect a fix for this issue coming soon.

@thejoshwolfe
Copy link
Owner

published yauzl 2.10.0 which replaces backslashes by default. let me know if this solves your problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants