[RESOLVED] Compress option on USB drive

[IronRod]

I just noticed a "Compress..." option when I right-click on a mounted USB drive. What does this do?

Taking this option, it displays a dialog "Compress" and allows for a "Filename", file type extension (e.g., .tar.gz) and "Location". I entered a name, left it at the default location (home), then clicked [Create]. I assumed this would compress the drive image and save it as the name file-type in the selected location. But no other notification appeared (e.g., Done, etc.) and, after waiting several minutes, I could not find any new file of that name and type in home or anywhere else.

RESOLUTION: See the last comments on the resolution. It ended up being a defect.

[linux-rox]

Works for me. Try specifying a location, e.g., Desktop or Downloads. But the default also worked, putting the tarball in my home folder.

By the way, File Manager doesn't think of it as a device. Rather, it's thinking of it as a folder with files in it. You can't compress a device.

[IronRod]

I tried again and selected the Download folder and then again with a specific folder I created (/home/<user>/Images). Still nothing appears.

After clicking [Create] the "Compress" dialog just disappears. But I expect there'd be some kind of progress bar or something showing the progress. What should I see or expect after clicking [Create]?

[linux-rox]

After clicking [Create] the "Compress" dialog just disappears.

Same here. Then I check target and there's the tarball. Indeed, if I open dual pane view, I can see it appear. Almost instantly in my case, as the flash drive only has half-a-dozen files on it. Have confirmed the tarball extracts correctly, by the way.

Which version of Mint? Which desktop? What's the format of the USB drive? Have you tested with a different flash drive?

[IronRod]

I've tried several different USB drives: 2GB FAT, 16GB NTFS, 64GB exFAT, and others. Same result; no file appears in the target folder.
I've tried the default (home) folder, ~/Downloads, and a folder I created ~/Images. No file appears in any of these.

Running Linux Mint 21 with DE of Cinnamon. This is a clean install I made only recently and haven't done anything to it in terms of modifications. I just stumbled upon the "Compress..." option, thought it was interesting, and -- nothing. I'm not totally new to Linux or Linux Mint but this seemed like a noob question (one from which others might benefit) so posted it here. Not sure what log(s) I might check to figure out what is failing.

Code: Select all

~$ uname -r
5.15.0-52-generic
~$ cat /etc/os-release 
NAME="Linux Mint"
VERSION="21 (Vanessa)"
ID=linuxmint
ID_LIKE="ubuntu debian"
PRETTY_NAME="Linux Mint 21"
VERSION_ID="21"
HOME_URL="https://www.linuxmint.com/"
SUPPORT_URL="https://forums.linuxmint.com/"
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
PRIVACY_POLICY_URL="https://www.linuxmint.com/"
VERSION_CODENAME=vanessa
UBUNTU_CODENAME=jammy

[linux-rox]

Didn't even think to ask which version you are running. Did my initial tests in Cinn 20.1, but also works for me in Cinn 21 (just checked). Compressing an 8 GB FAT flash drive I happened to have handy. Anyway, sorry, can't think of what might be causing the problem.

[IronRod]

Thanks. I also tried selecting some other formats; e.g., .cpio, .tar., etc. But still nothing.

I wish I knew what it is doing/running once clicking [Create]. Not even clear whether this is a file manager thing or something inherent to LM. If I knew the command line, I could at least do some further investigation. Any guesses?

[linux-rox]

Almost certainly file manager is using tar (a command line app) under the hood. So, if you want to poke around, that's what you should poke with. Start by confirming it's installed. In Terminal, run tar --version. Then do an internet search, e.g., linux compress folder turns up a bunch of hits.

By the way, have you tried compressing any regular folders, i.e., not USB drives?

[IronRod]

By the way, have you tried compressing any regular folders, i.e., not USB drives?

Great suggestion. I tried that -- created a new document in ~/Downloads and then did the right-click on that folder and selected "Compress..." I took the default options (name="Downloads", type=.tar), and it dutifully created a Downloads.tar file.

So, I tried doing this on just a folder of a USB and was successful with this. In both tests, right-clicking a folder of the USB drive and using the Compress option resulted in a file being created as expected. But it still does not work using "Compress..." on the entire USB drive.

I then tried using tar at the command line and compression of the entire USB drive worked. It created the test.tar.gz as expected.

Code: Select all

~$ tar -cvzf test.tar.gz /media/<user>/TOOLS

The 'tar' version is 1.34.

[linux-rox]

That's pretty good progress. At least now you know you're not trapped in a black hole.

I'm still puzzled by the fact the GUI option won't work on the /media/<user>/TOOLS folder. As mentioned earlier, in Linux, a flash drive mounted to the file system is just a folder. To confirm, you're right-clicking that folder from /media/<user>, correct? Indeed, I don't think it's possible to do what you've been describing any other way. If you Go > Computer, you will see the flash drive, but there's no Compress option on the right-click menu.

Another thing you could try, in the nature of a workaround, is to open the TOOLS folder, select all (Ctrl-A), then right-click and Compress. FWIW, that works for me and I get all the contents in a single tarball (as opposed to a separate one for each file or folder).

[IronRod]

Another thing you could try, in the nature of a workaround, is to open the TOOLS folder, select all (Ctrl-A), then right-click and Compress. FWIW, that works for me and I get all the contents in a single tarball (as opposed to a separate one for each file or folder).

That worked as expected. And, as I would expect for a long process, it displays a progress bar as it is compressing and creating the output file. I can get this to work pretty much anywhere except when I right-click on the icon from the desktop; i.e., the icon that appears on the desktop after inserting the USB drive. And, as shown previously, a tar command on the drive mount location works successfully.

Sounds like a defect to me -- except that it works for you.

[linux-rox]

Not sure it's important, but sounds like the answer to my question is "no." For grins, try again using File Manager. In the left pane, select File System, then /media and /<user>. What happens if you right-click and compress the folder corresponding to the USB drive?

FWIW, both ways work for me (just checked), but the File Manager method is what I've been using all this time. As it happens, I don't like clutter on the desktop, so I always turn off display of mounted devices. For that matter, I always turn off auto-mount, but that's not relevant to this problem.

[IronRod]

For grins, try again using File Manager. In the left pane, select File System, then /media and /<user>.

That actually worked. It is notable that when I right-click on the TOOLS folder from within File Manager and select "Compress...", it defaults to the name of the folder; i.e., "TOOLS". When I right-click on the TOOLS icon from the desk-top and select "Compress...", it defaults to the name "TOOLS.volume". That seems significant but unsure exactly how.

What default name do you get if you right click on the desktop icon?

BTW: As to your point about desktop clutter: I, too, tend to keep a pretty clean desk-top in most cases. In this instance, it is just a fresh, unmodified install of LM 21 that, at this point, I'm using for exploring and research. I'm a real fan of LM/Cinnamon and would so switch to LM full time if I didn't have other obligations that require Windows. My long-time desire is to get LM running on my Chromebook, but that's another story. (It is currently running Ubuntu 22.04 but still requires some workarounds for a couple devices that aren't well supported.)

[linux-rox]

What default name do you get if you right click on the desktop icon?

As I recall, it proposed the .volume extension, but saved under the partition label only, i.e., in my case, SHUTTLE.tar.gz. Interestingly, I can no longer confirm that, as compressing from the desktop no longer works (although the File Manager method still does). Apparently your jinx is contagious.

... other obligations that require Windows.

FWIW, I've moved to the middle ground where my main system is Linux and I run Win10 in a VM. There are some hassles with this approach, especially as regards switching active windows, which requires different keystrokes to switch out of the VM, but on the whole it works for me.

[IronRod]

Apparently your jinx is contagious.

Dang... Well, on the other hand, maybe I can now report it as a defect...

[linux-rox]

The Mint website has instructions for how to file a bug report. Looks like a Cinnamon desktop issue to me. And, FWIW, I don't think the developers will consider the File Manager workaround sufficient to moot the point, as that's not something ordinary users can be expected to know.

Edit: Decided to check MATE also. Similar problem, i.e., can't compress from the Desktop, but at least get an error message:

Compress-Failure-MATE.png (8.96 KiB) Viewed 548 times

Same message in both LM20 and LM21. Changing destination location makes no difference. File Manager method works, though.

BTW, I did all my prior tests in VBox. As I had pulled out a backup computer to boot my LM21 multi-boot USB drive (don't have a Mate 21 VM), I tested Cinn 21 again, this time on bare metal. Same outcome, i.e., no tarball when compressing from the Desktop, but File Manager method works fine.

Finally, the issue doesn't arise in XFCE, as mounted volumes don't appear on desktop. File Manager method works, except called Create Archive.

[IronRod]

Submitted an issue to the Github linux/cinnamon project: https://github.com/linuxmint/cinnamon/i ... 1471888459

[linux-rox]

Well done. Seems to have worked. Issue closed an hour later based on what appears to be a coding fix.

[IronRod]

Good news, indeed. I wasn't sure if it was a Nemo issue or Cinnamon issue -- and guessed wrong. I went with the latter since the operation generally worked fine in Nemo so I thought it might be a desktop issue. In any case, they clearly recognized where the fault lay and resolved it -- which is what we wanted.

It's really interesting that it originally worked for you and then, later, failed. Gotta wonder why on that...

Thanks for sharing your thoughts in all this. See you 'round the forums.

[linux-rox]

Gotta wonder why on that...

Gremlins? Seriously, I'd assume I did something "wrong," but can't reproduce the original result no matter what I do. It's a mystery.

Anyhoo, all's well that ends well. Congratulations on a successful resolution.