Open omnicron-llc opened 2 years ago
That sounds about as fun as changing file cases with git. Is it extracting to an existing directory, that already has 'coffee.html'?
It's extracting coffee.html first, and then when it attempts to extract Coffee.html it fails on a case-sensitive FS. (To clarify: "coffee.html" DOES exist in the partial destination directory and does appear to have correct contents)
Obviously this case will also cause problems (when correctly handled) on a case INsensitive FS, because of the collision, but that is beyond the scope of this issue - and beyond the scope of an archive extraction utility to begin with; if someone tries to extract two files that map to the same name on a destination FS, I would consider that "undefined behavior" and not worry about it beyond making sure whatever DOES happen does not cause a crash or data corruption beyond those two files - presumably one file or the other would be overwritten, but that's about the only logical outcome in such a situation.
Thanks for the clarification.
A client has uploaded a tar file with the filename 'Coffee.html' - when I attempt to extract this file, I get "Cannot create file, path = '/Coffee.html' (OS Error: no such file or directory, errorno = 2)
When I examine the filesystem, I see the file 'coffee.html' (note lowercase c) exists (the archive contains both Coffee.html and coffee.html) but presumably some collision check is case folding the filename before creating the uppercased file.
This reminds me of https://github.com/flutter/flutter/pull/9571 - same behavior, same general failure mode. I'm not sure why people get it in their heads that tampering with filename casing is a good idea - I just am not sure if the issue is in archive itself or a dependency.