I hope this doesn’t violate the low-quality rule. For those who don’t know, when you right click an archive in Dolphin, the extract menu has a “Extract archive here, autodetect subfolder” option and its absolutely brilliant! If you’ve ever extracted a zip, tar, etc and ended up with files splattered everywhere this feature will prevent that. Basically when you choose this option it will:
- Look to see if the archive has a top level folder, if it does, it will extract it normally
- If it does not (so all of the files are at the top level), it will automatically create a folder for the archive and extract those top level files into it
It’s something I really wish other file managers had, and is just another one of those features from the KDE team that gives me the “The developer(s) who created this also use this in their daily lives” impression (which is not to say that others don’t). You can of course just open your favorite archive utility and manually check, then manually make the folder yourself and extract the files into there, but this lets me skip those couple of steps and I appreciate that so much.
I legit miss that feature when I’m using other PCs
Absolutely, yep! I curse myself every time I just click “extract” forgetting that other file managers don’t do this, and end up with files all over the place
Holy shit, that’s awesome. I always get annoyed when there’s no top level and I have to make one manually. Thanks for sharing!
Or you make one because you’ve been burned so many times, and now your files are two levels deep.
Ugh I hate that the most
And it will only create a directory if the compressed file has more than one file inside It’s the perfect behavior.
I hate when archives are just a folder inside, now I gotta manually move the files up a level into the directory I wanted them in the first place.
I see this feature is for when there is no folder inside. I come across this a lot less personally.
no, no - the opposite is the actual problem: you extract in a non-empty folder and there’s no top directory in the archive. Now you have a bunch of files mixed up: the extracted ones and the ones that were there before you did it.
Even better when this happens on a Linux server with no GUI (bonus points if you don’t have much Linux experience yet).
Honestly now I am curious if there is a CLI equivalent. I always end up using tar’s
t
flag or opening a zip in vim to see if it has a subfolder as my current workaround…Oh this looks fantastic! I will be deploying this to all of my systems immediately haha!
You get Linux experience real quick when you make mistakes like that in a shell with no GUI.
mkdir newfolder; find . -maxdepth 1 -mmin -5 -exec mv "{}" newfolder \;
If you’ll forgive my compulsion to substitute all
find
s with Zsh globs:$ for f ( ^(newfolder)(mm-5) ) mv -i $f newfolder/
Assumed:
$ mkdir -p newfolder $ setopt extendedglob
Ahaha yeah, it’d be fine if it was always either way for me, but I personally prefer setting my folder up and then extract the archive into there, so I don’t have to rename it or whatever after extracting. So I would rather it have all the files in the top of the archive and not in a folder.
That’s perfectly fair! I always seem to have a 50/50 coin toss of whether there will be a folder inside the archive or not.
I think if things were more consistent for what I end up having, I wouldn’t mind it if archives didn’t have a folder or if they always had a folder, rather than the current state.
I suppose in your case, it would be cool if there were a config option to make this do the reverse, unpack the files within the subdirectory of the archive to your current directory.
The “autodetect subfolder” option handles both scenarios fine. This is actually what makes it useful! If I remember correctly, when there’s a single file or folder inside, it just extracts, otherwise it makes a folder with the same name as the archive without the extension.
Funny enough, I discovered this a couple of weeks ago when I extracted a zip file with the top option and I had like 100 files all over my downloads directory. I was so pissed I had to delete them all one by one and make sure that I don’t delete the files that I actually want there. It was so painful. Then looked at the bottom one and it made sense and it was an “aha I fucking love kde” moment.
Doesn’t
Ctrl+Z
undo the extraction? I may be dreaming, but I remember there was a fast option to delete all the files extracted. Anyway, we already know about autodetection B)
You explained it, so it’s high quality. Very cool
It’s one of the very few things I miss from Windows - the 7zip shell extension had the same feature, but literally put the autodetected folder name in the menu so you knew what it would be before even clicking. Such a small thing but so significant a UX boost.
Yeah, when I migrated back to Linux this was a baffling omission to me. I used it a lot in Windows and 7zip. Luckily I realized Plasma is awesome and Ark has this feature. Still kind of miss 7zip though.
I love them too, such a great and simple feature
I think this is the default behavior in GNOME as well
When I am on Windows and extract, I always get the top folder, but then it appears some compressed a folder with that exact name so I end up with two folders. Have to clean that up manually is really bad. I use Windows built in for zip and Winrar. Never even though about this problem before that it could be handled that way. Thanks for the tip!
It’s such a great feature I use it all the time!
This has totally slipped my eyes for so long! Thanks 😊
It’s a useful feature, but I couldn’t have guessed your explanation from the name.
It seems to me that the default extract option should work that way and this option should just be removed from the menu.
I have never once wanted extracting an archive file to litter the current directory with files.
The only exception would be an archive which contains a single inner file.
deleted by creator
It’s something I really wish other file managers had,
This has been the standard behavior for gnome for like around 20 years…