managed-lzma
managed-lzma copied to clipboard
weltkante
fix unable to extract some 7z archives
my suspicion is its archives that have a file name that matches also a folder name.
This was the archive I was unable to extract... https://avalonstudiotoolchains.blob.core.windows.net/avalonstudio-debuggers-jlink/AvalonStudio.Debuggers.JLink.win-x64.6.4.4.0.7z
continue instead of throw exception fixes it.
Code used to extract is: https://github.com/VitalElement/AvalonStudio/blob/azure-packages/AvalonStudio/PackageManager/PackageManager.cs#L297
@danwalmsley this doesn't seem right, the location you changed should only get triggered for files (or more exactly, something with a data stream - directories have no data streams in the 7z format). If a filesystem entry has the directory attribute set then it shouldn't have been added as a file with data into the archive, but as a directory. Maybe something went wrong when creating the archive - alternatively, I've seen cases where third party implementations take "unused" bits and give them their own meaning. Do you know how the archive was created?
I'd like to have a look at the file to determine how the "official" client would treat it. It might just be that the official client clears or ignores invalid directory flags, but then the continue would be the wrong fix here, because it drops the file entry.
Unfortunately the linked file is no longer available online, if you can find another one or still have a copy around I'd like to take examine it.
Try this link: https://avalonstudiotoolchains.blob.core.windows.net/jlink/JLink.win-x64.6.4.4.0.7z
btw is your code based on https://github.com/monemihir/LZMA-SDK/blob/master/src/SevenZip/Compress/LZMA/LzmaDecoder.cs
perhaps integrating that could make the code faster?
Thanks, I can reproduce it with that archive. Its an odd archive because all the directories have zero byte streams, usually the directories don't have streams. Anyways, since the official 7z client can read the archives its obviously a bug in my reader. It might take a while until I get the time to verify the correct behavior though.
Regarding you other comment, my code is based on the C/C++ version of the LZMA SDK. The C# version you quoted is based on a Java port. I prefer the C/C++ version as reference since thats the one actively maintained.