When opening an archive in Files, the file is immediately extracted in a folder named based on the archive name. Even when using Extract To, a folder is created. Can this behavior be modified so that no folder is created?
Hi.
No, it’s not possible to modify this behavior.
(There is an exception to that behavior: if the archive contains a single item, that’s extracted directly, not into a new folder.)
Do you have cases where this behavior is obviously wrong? Maybe we can improve the heuristics to do the right thing.
Here is possibly one case: if the archive is the only file in a folder.
1 Like
Very simply: most of the times, I want the files in the archive to end up in a folder that is not named after the archive. With the current behavior, I now need an extra operation to move the extracted files to the expected folder (which may exist, so I can’t just rename the new folder). So it would be much better if that behavior could be configured.
In that case the archive would be included in the folder where its content is extracted to, so it’s not exactly the ideal result. (Unless we automatically delete the archive file after extraction…)
I now need an extra operation to move the extracted files to the expected folder (which may exist, so I can’t just rename the new folder).
If a person uses “Extract To…” to pick a destination folder, it’s reasonable to assume they want to extract the contents directly into that folder, not into a subfolder (they would have created a new folder in the destination chooser if that were the case).
So I think we should change this behavior for “Extract To…” (but not for “Extract”).
This will require someoneelse to put in the effort, as I don’t have time to do it. The implementation will require the extract operation to handle possible file conflicts (e.g. overwriting existing files with the ones being extracted) the same way we already do for copy/move operations.
It would be so much worse if it could be configured.
I’ve filed an issue about this:
1 Like
I would agree. I found it very confusing that, when using Extract To, it still extracts the files to a new sub-folder.
Because “Extract” creates a subfolder, it’s not unreasonable to expect “Extract to” to create a subfolder in the destination. When there is ambiguity, it is better to perform the least damaging task, which would be to create the subfolder. If I expect a new subfolder and find that I have just created several hundred files in a directory already full files, it will be quite a job to fix it!
Would the ambiguity be removed if the labels were as follows?
Extract to [archive name]
Extract to…
Given that extracting into an existing directory requires an algorithm for the resolution of duplicate file names, would something like the following be more appropriate, where the existing Merge dialog is used for duplicates?
Extract
Merge Archive into…
1 Like
Did you ask if it was a UI problem?
@Mythical5th Thanks for the counterpoint and thoughtful proposals. Would you mind to post the same comment on the issue? Alternatively, I can quote you there.
Thanks, you can quote me.
1 Like
Another very unexpected behavior: if a folder with the same name as the archive already exists, then a new folder is created with “(2)” appended to it. In such case, one would expect that the files are extracted to the expected folder rather than a different one be created.
Why is it unexpected? The user has not explicitly selected the existing folder to be replaced.
If a folder with the same name already exists and a new folder is to be created, it cannot use the same name. Hence (2) being added.
1 Like
I have never seen an archive manager behave this way, whether on Linux, Windows or Mac. The behavior any regular user would expect in such a scenario is that the archive is extracted in the existing folder (asking in case of overwrite), and not end up having to execute an extra step to move the location that was expected in the first place, and deleting the unwanted directory.
Just randomly reinventing a new set of behaviors in complete disregard of established practices is not good design at all.
I’ve seen file roller behave that way. I’m not sure what the circumstances are that make it do that, or even if it’s been changed not to do it, but every time it did do that, it was not what I expected or wanted. Others agree.
1 Like
Showing disrespect and contempt for the UX design work that went into this doesn’t really help your cause. Instead it makes me stop taking your feedback seriously.
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.