elfmz
Unzip with parent directory
My .zip file (project.zip) has this directory structure. | aptgroup - iscala2uno | connect - obclock | ...
I navigate to the aptgroup directory and select the iscala2uno directory, and then press F5 to copy. It unzips the aptgroup directory (but not the files inside it) and the iscala2uno inside it. I would assume it should unzip only the iscala2uno directory and NOT its parent directory also! Same with the connect directory above.
Is this normal, is this something I could change myself?
Ok, nice to know. Can I modify the settings or is it in the source?
I dont think so. The problem that multiarc uses external unarchivers to extract files and typically there two possibilities: extract with full pathes and extract without pathes. And what you want is in the middle. However, since multiarc started to be unpacking engine too by using libarchive, that can be workarounded for formats extracted by libarchive, including zip. And i've just commited workaround. Note that if you've changed some archivers command lines in multiarc settings you might have to reset that settings.
Great :-) Then I'll just look forward to the next Alpha in my update manager. Btw, It works the right way i FAR3 on Windows, maybe they coded the same workaround :).
FAR3 by default has ArcLite that is unarchiver by itself and thus also not limited by 3rd-party tools abilities.
I have to thank give a huge thanks to you and the other contributors! Moving to a Linux machine after using far-manager for years and finding mc... Not that mc is bad, but my fingers are used to certain keystrokes. Huge thanks!
And what you want is in the middle.
Can't we just do mv afterwards by ourselfs for such archivers? :)
I had same idea but problem that it theoretically may overlap existing directory and following mv will move all together thats would be not very good.
I had same idea but problem that it theoretically may overlap existing directory and following mv will move all together thats would be not very good.
So can we do this only then there is surely no existing directory with the same name?
I would say that if you're extracting a file/directory A into directory D which has A already, then you're making a conscious decision to overwrite the existing A. Or maybe even get the usual "Overwrite?" prompt when moving A into D.
However, since multiarc started to be unpacking engine too by using libarchive, that can be workarounded for formats extracted by libarchive, including zip. And i've just commited workaround.
arclite (that handles paths correctly) uses 7zip internally. We also use 7zip sources for 7z format. Aren't they capable to do the trick as libarchive does?