unzip doesn't properly handle archives with backward slashes under Linux.
Example archives:
https://sourceforge.net/projects/screenruler/files/v.0.8.1/ScreenRuler-v.0.8.1-Portable.zip/download
If you try to unpack any of them, you'll get funny results.
As always, a program version number would be helpful, but it probably
doesn't matter much in this case.
I just ran into this problem in a Ford/Microsoft SYNC software update
kit a few days ago.
That depends on your sense of humor.
One could argue about what "properly" means in this case. Such
archives do not conform to the zip archive standard, which requires a
forward slash ("/"), not a backward slash ("\") as the path separator.
See section "4.4.17 file name" in:
It would be interesting to know exactly how such non-compliant
archives are created. (Our Zip program does it properly when it's used
on Windows, for example.)
The (Apple-supplied) Archive Utility app on Mac behaves the same way
with such non-compliant archives. (Ford tells its victims with Macs to
download and use a (free) third-party app, "The Unarchiver", which works
for Ford's non-compliant software update kits. And to disable Safari's
default behavior, which is to extract the contents of a zip archive
automatically when one is downloaded, using built-in tools, which don't
compensate for a non-compliant archive. It's a mess.)
The current behavior of UnZip (or Apple's Archive Utility app) makes
some sense, because "\" is a legal (albeit unpopular) character in a
file name on a Unix-like file system, so it would be an error always to
convert "\" to "/" on any Unix-like system. Both programs comply with
the standard. The program which made these non-compliant archives did
not.
One possible solution would be to enhance UnZip to convert "\" to "/"
in the (path) names of archive members (in a non-compliant archive) when
the archive member is marked with a source-file-or-operating-system like
MS-DOS, or another system where "\" is the normal directory separator
character. (See section 4.4.2.2 in the APPNOTE.) There would need to
be a command-line option to enable/disable this behavior.
I don't see any quick-and-easy work-around. I might write a script
which renames a file with "\" in its name (and creates the required
directories).
You might also complain to the people who distribute the
non-compliant archives.
unzip-6.0-53.fc35.x86_64 : https://src.fedoraproject.org/rpms/unzip/tree/rawhide
In my 25 years of using UNIX OSes I've not seen a single filename containing back slashes. I'd just go ahead and convert \ in filenames to / automatically but I'm not a C programmer.
It's a lost cause. Lots of these archives are not maintained, their creators wouldn't bother.
I've "solved" the problem for myself by using WinRAR under Wine. Nothing native under Fedora (Linux) can properly unpack such archives.
Last edit: Artem S. Tashkinov 2022-04-03
More than I had realized. I apologize. Initially, I was too lazy to
do the extraction; I just looked at a listing ("unzip -l"), and saw the
backslashes. "Trust no one," I always say. So, today, I actually did
the work, and noticed that UnZip apparently already handles this
situation, which my tired, old brain had forgotten. Around here, on a
Mac, for example:
The rest of the directory hierarchy looks fine, too.
That "unzip6" executable was built from the original UnZip 6.00
source. The "usr/bin/unzip" which Apple ships with the OS works the
same.
It's similar for your other example (although you don't get the
warning until the first backslash gets processed, and that's later in
this case):
I think that these results are pretty funny, but perhaps it would be
helpful if you provided a serious problem report, showing exactly what
you did, and exactly what happened when you did it.
All that experience, and "you'll get funny results" is your idea of a
problem description?
I need to apologize.
unzip under Fedora 35 unpacks both archives with zero issues
The issue is Midnight Commander which tries to parse unzip -l output and fails spectacularly: https://midnight-commander.org/ticket/4238
Still, I've identified a bug:
$ unzip macintosh.js-win32-ia32-1.1.0.zip 'swiftshader\libEGL.dll'
Archive: macintosh.js-win32-ia32-1.1.0.zip
caution: filename not matched: swiftshader\libEGL.dll
$ unzip macintosh.js-win32-ia32-1.1.0.zip 'swiftshader/libEGL.dll'
Archive: macintosh.js-win32-ia32-1.1.0.zip
caution: filename not matched: swiftshader/libEGL.dll
Last edit: Artem S. Tashkinov 2022-04-05
Ok.
I can believe that.
Or, it's not a bug in UnZip, but you didn't treat "\" as a special
character? Try "\\" instead of "\"? Using your other (smaller) example
archive:
It works for actual extraction, too:
I wouldn't bet that the UnZip documentation mentions this, but it's
pretty standard behavior on "UNIX OSes". Your apostrophes get your
backslash past the shell, but UnZip still needs to deal with it, and
it's special to UnZip, too. Another (appostrophe-free) possibility:
As usual, many things are possible.
In which "the output"? A path in the (non-standard-compliant)
archive might include "\" separators, but a name in the local
(UNIX-like) file system will include "/" separators. On a VMS system,
for example, the in-archive names are the same, but names in the local
file system look still different:
What, exactly, don't you like about what UnZip does? And what,
exactly, would you like it to do, instead?
Last edit: Steven Schweda 2022-04-06
Not on our tributary. It might be helpful if someone explained the
actual situation in that other forum.