Can't Unzip Folder Entries From Windows Built Zip Archives

[el-gee]

This issue seems related to: #61 however I decided to create a new issue in case my hunch was incorrect.

Relevant Info

• OS - win 10 1803
• Zipping tools tested: Powershell 5.1 Compress-Archive and the integrated system.io.compression.filesystem Zipfile class (that powershell also uses under the hood).
• Archiver versions tested - release 2.0 and current master branch

Observed High Level Issue

• When attempting to unzip a file (using archiver that has been embedded in another utility) I get errors like C:\Users\lg\temp\testfoldera\0\1\a: making directory for file: mkdir C:\Users\lg\temp\testfoldera\0: The system cannot find the path specified. And can see that in the directory structure that should have been created there are "blank files" instead of some directories (aka files with no extension that in the actual zip are also directories).
• The issue can be recreated using just the Archiver utility as well.

Current Theory

• Line 195 of zip.go needs to be updated to support Windows styled path endings: https://github.com/mholt/archiver/blob/master/zip.go#L195
• It seems like what's happening is that any time you have a directory entry in the zip this line will check using the suffix heuristic and create the dir as a dir rather than a file. However, because on windows directories are stored with \ endings (depending on util, i did a very quick test with 7zip which seemed to force everything to unix style), this heuristic fails.
• The consequences here seem to usually be pretty benign b/c the only "normal" time I could find to have folder entries in the zip was if they were going to be a leaf node in the file-system. Otherwise the path was always implicit in the remaining files.
  • HOWEVER the new powershell compress-archive makes some really weird zip structures that do have folder entries strewn about and make the issue much more prevalent. Not 100% sure but it feels like whenever you have a folder that only contains only folders it will perform this behavior.

Minimum Test Case

• make a folder and in it create another folder along with a small file. The point here is really you just need some bits on disk, zip utilities seem to try and get cute if there's not actually any data you're trying to zip.
• Zip the folders. Then try to unzip with archiver open, notice it's the inner folder is now file.

Thoughts

• In general it feels like the root issue here is the heuristic of looking for a char suffix to indicate dir type isn't as robust as desired.
• Unfortunately, I couldn't get the isDir() function to work listed here: https://golang.org/pkg/os/#FileMode.IsDir which seems like the obvious solution if it did work.
  • Although, this perhaps could be because the utilities that create the zips don't honor the isDir bit in the zip file format.
• If there isn't a working method like isDir perhaps something like os.PathSeparator could get halfway there.
• updating the line in question to if strings.HasSuffix(zf.Name, "/") || strings.HasSuffix(zf.Name, "\\") { did solve my use-case.

[mholt]

It's possible that this was fixed in #99. Or maybe not. 😇 Feel free to re-open if it's still a confirmed issue.