GNOME Bugzilla – Bug 771418
when extracting archives, create files/folders in the same clever manner that file-roller does
Last modified: 2016-10-29 14:06:56 UTC
Nautilus compression/decompression integration is trying to replace basic functionality of file-roller. However, when extracting archives, the output file names are a clear step backwards. File-roller uses the following very smart behavior: 1. If the archive contains only a single file or a single directory, extract it directly and do not create "enclosure" directory for it. 2. However, if that output file/directory name already exists, go to 3) instead. 3. If the archive contains multiple files/directories in its top level, create a directory for it and the put the contents there. Make sure this "enclosure" directory name is unique (if it already exists, generate a new one). I loved file-roller for this smart functionality. It saves a lot of work by avoiding to create unnecessary directories. Nautilus currently always creates the "enclosure" directory, even in cases described in 1). That makes nautilus-extracted archive to be more chore than file-roller-extracted archives. Please use the same clever approach when extracting archives as fille-roller does. Thank you. nautilus-3.21.91.1-1.fc25.x86_64 file-roller-3.21.90-1.fc25.x86_64
This is how is supposed to work, so maybe it's a bug in the heuristics. Please provide the info of the names of your file and the directory inside, we base the heuristics on that. For instance if the compressed file has a different name than the directory inside we create an enclosure directory, otherwise would be too confusing to know from where that file appeared.
(In reply to Kamil Páral from comment #0) The functionality in Nautilus is not a step backwards, but a step in a different direction. We wanted to ensure that the extraction output and the archive share the same name, without extensions. The "enclosure" directory is only created if the archive's top level file/directory and the archive itself have different names (or if the archive does not have a single top level item). In this way, locating the output becomes an intuitive process as users can predict the name of the extracted file/directory. Don't you think that in this scenario it is reasonable to deal with an extra directory?
(In reply to Carlos Soriano from comment #1) > Please provide the info of the names of your file and the directory inside, > we base the heuristics on that. If I compress 'sample.odp' as 'sample.zip', the extraction works (just 'sample.odp' is extracted). But if I compress it as 'sample.odp.zip' (which is the default filename when I use the file-roller-based 'Compress' context menu in nautilus), it's extracted to 'sample.odp/sample.odp'. Which is weird. The compressed file name is clearly the same as the archive name (even a better match than in 'sample.zip'). Should be trivial to fix, though. (In reply to Razvan Chitu from comment #2) > The functionality in Nautilus is not a step backwards, but a step in a > different direction. We wanted to ensure that the extraction output and the > archive share the same name, without extensions. The "enclosure" directory > is only created if the archive's top level file/directory and the archive > itself have different names (or if the archive does not have a single top > level item). In this way, locating the output becomes an intuitive process > as users can predict the name of the extracted file/directory. Don't you > think that in this scenario it is reasonable to deal with an extra directory? Thanks for explanation. I'm not fully convinced personally, but I must admit it's probably a better default for general audience. When I renamed my archives to match the compressed directory name inside, it started working as expected (with the single exception mentioned above).
*** Bug 772836 has been marked as a duplicate of this bug. ***
We decided that a compressed file is always like a folder, having one item or multiple items. And I think staying with this assumption creates a consistent behavior, although I can see is inconvenient for when it's one file, realistically I don't expect much use cases of compressing just one file. Having this assumption help us also technically, which is something nice, but not a reason to do it or not. So closing as wontfix.
Do I understand correctly that 'sample.zip' is now going to be extracted as 'sample/sample.odp'? And 'sample.odp.zip' as 'sample.odp/sample.odp'?
(In reply to Kamil Páral from comment #6) > Do I understand correctly that 'sample.zip' is now going to be extracted as > 'sample/sample.odp'? And 'sample.odp.zip' as 'sample.odp/sample.odp'? So I double checked (that's why it took long) with Razvan, because I had the feeling something on my logic was wrong. So yeah no, it should work as you expect in all the cases you mentioned. Patches will come soon.
(In reply to Carlos Soriano from comment #7) > (In reply to Kamil Páral from comment #6) > > Do I understand correctly that 'sample.zip' is now going to be extracted as > > 'sample/sample.odp'? And 'sample.odp.zip' as 'sample.odp/sample.odp'? > > So I double checked (that's why it took long) with Razvan, because I had the > feeling something on my logic was wrong. > So yeah no, it should work as you expect in all the cases you mentioned. > Patches will come soon. Patch has arrived. https://bugzilla.gnome.org/show_bug.cgi?id=773520
*** This bug has been marked as a duplicate of bug 773520 ***
*** Bug 773670 has been marked as a duplicate of this bug. ***