Please make it more clear that properly ejecting storage mediums is very important on Linux

[runningvisor]

When us new users come from Windows, we assume once the file transfer dialog closes, the OS is done with the drive and therefore, it's safe to just remove the drive without thinking too much about it. You can even remove the drive during a transfer on Windows and more often than not, it'll be fine (just missing files that weren't moved).

On Linux-based systems, your data is moved to the RAM first. The dialog implies otherwise, but it's understandable why it's done this way. I'm now aware of the fact that this is just how Linux works, but there's no way us new users would know that until it's too late (and possibly many more times due to habit), especially if the look of Mint is meant to accommodate Windows users ("if it looks like Windows, it must function like Windows").

A possible solution for this would be to "sync" data immediately after transfer by default (with a GUI option to disable) and show this in the file transfer dialog by changing the finished progress bar to the indeterminate "bouncing" animation with something like "Almost done. Important: do not remove the drive".

Rendered example:

0001-0858.mp4

This behavior would also apply to ejecting the drive, replacing the writing data notification (another rendered example):

0001-0837.mp4

This would sufficiently replace nemo issue #2172 (and would be much more obvious), but that issue is about 6 years old at this point so I'm not sure how much hope I have for something like this, but I feel this is pretty important.

[billyswong]

You may come and support my proposal in https://github.com/orgs/linuxmint/discussions/429

[runningvisor]

That proposal was made a little over 2 years ago. How likely would something like this even get implemented and would it be possible with an obvious UI like this? I was scrolling through old issues and it was quite discouraging to see all kinda of quality-of-life improvements just being ignored. I up voted your proposal.

[billyswong]

@runningvisor Developers' time budget are stretched thin by the X11->Wayland transition. Cinnamon, MATE, Xfce all suffer from that.

[Fantu]

The main problem lies with users who don't safely remove devices as they should. In over 20 years, I've seen far too many problems because of this. And the fact that they're still primarily using FAT as FS, unfortunately without journaling, means they have many serious problems.
I think adding technical data visualization is almost useless, it is information useful almost only to users with a little experience that does not cause problems.

Regarding the cache usage and the "delay" in effective writing to disk, it's not a Linux problem; it's also present in Windows.
In Windows, it seems worse to me because there are cases where, even if the drive has finished writing and there are apparently no more open things on the external volume, it prevents deactivation and requires a longer wait or even a reboot.
So, users who need to remove the device and don't want to shut down or restart Windows unplug it anyway, and then, because of that problem, they're more likely to unplug it immediately, even in normal cases, without waiting.

[ost-guy-comeback]

Yes fantu really you are correct

[cplittlfield]

Actually, the advice to safely eject USB sticks before removing them from the port has been standard advice for decades.

It appears, however, that Microsoft got tired of dealing with Windows users who pull out the sticks prematurely and made some sort of change, or at least this is what I understand from a thread in the forums about this topic. But essentially the problem is one of educating users that Linux Mint operates differently.

The solution I would prefer is for a system modal message to the effect of "DON'T PULL OUT THE USB STICK JUST YET" to be displayed, since since such a message will prevent other uses of the machine until it goes away. The message should remain on screen until the buffer is fully written to the disk. Then it could disappear and restore normal functioning. If that won't get the message through, I'm not sure what else will help, apart from losing essential data a few times until the lesson is learned.

[Fantu]

I don't think there's a good way to implement something like this. The user can physically remove the drive, and there would be a trigger that could only be used once the removal has already occurred. Displaying something obvious or invasive every time a write is in progress on removable devices (which would also include internal drives that support hotplug) would be more annoying than helpful.

[mtwebster]

The solution I would prefer is for a system modal message to the effect of "DON'T PULL OUT THE USB STICK JUST YET" to be displayed.

This is already what should be happening. I'm reviewing both Nemo and Cinnamon's eject/device-removal paths to ensure it happens consistently, to add to some improvements already done for the upcoming release.

Displaying something obvious or invasive every time a write is in progress on removable devices (which would also include internal drives that support hotplug) would be more annoying than helpful.

But that will never be as annoying as losing data. You wouldn't see anything if there's no ongoing write anyhow.

[Fantu]

@mtwebster thanks for your good job improving this, from a fast look I don't see any invasive things in your commit, regarding my message I thought that the user was requesting something more evident with any writing to removable drives but maybe I made a wrong assumption.
More specifically, what I meant about the many (too many) users who don't even try to click things like unmount or safely remove, but simply eject (phisically) the device.
And thinking about something related to those, the only thing that came to mind was something invasive while I was writing (which is not good).

[cplittlfield]

@Fantu I was being semi-sarcastic in my earlier post, but the underlying point is valid. Users need to be told, in unmistakable fashion, before they attempt to remove the stick that there may be problems resulting from premature removal. I loathe system modal messages in most cases, but I don't see any other way to capture the user's attention before the damage is done. Do you have a better solution?

And I agree with Michael that annoying system behavior is better than data loss. Although perhaps the message could contain a button reading, "I understand and promise to behave. Any data loss is now on me." (What do you think, @mtwebster ?)

[Fantu]

Perhaps I could think of something more possible, such as a warning dialog (about the consequences of what was done, the risks to the data) if the disappearance of a device containing a filesystem that hadn't been unmounted is detected, perhaps even if "safely remove drive" wasn't selected.

However, I haven't checked the implementation thoroughly in udev and other parts, and there might be cases where it could be problematic, for example, in the case of a faulty device that "appears" and "disappears" continuously, but these should be fairly rare, and perhaps a way could be found to limit the "warnings" to a maximum of one in defined amount of time.

EDIT:
_onDriveDisconnected in automountManager.js in the commit saw before can be a start faster that udev for device remove.
As for checking whether the volume was unmounted, I don't know if it's as easy. We'll need to see if GMount changes before that happens.
Otherwise, perhaps with GLib.UnixMountMonitor, if there's any trace of a mountpoint to a device that's no longer present.
These are things I'd need to verify in more detail and with practical tests.

[mtwebster]

The behavior for 6.8 will be a 'persistent' notification in the corner - you can dismiss or ignore it just like any other notification. It will stick around until it's safe to remove the device, then show another notification stating that. This isn't new behavior, but hasn't been consistently applied across all the ways a user can eject a drive until now.

For certain situations, like you're playing a dvd with Celluloid and hit the physical eject button, a dialog (we have non-modal ones now) showing which app is using the drive will pop up. You can cancel or force the eject (and the app will just have to deal with it). This isn't 'safe removal' protection really, just a 'hey you're using this', so it's a bit more obvious.

[Fantu]

@mtwebster While working on this (a warning when a device is unplugged while it's still mounted) I ran into two things, plus a question:

1. Wrong icon name in the unmount notification. CinnamonUnmountNotifier in js/ui/cinnamonMountOperation.js uses xapp-media-removable, which doesn't exist in the icon set Cinnamon uses now: icon names were switched to XSI in 890f6f7f9 and xapp-symbolic-icons only ships xsi-* names, so the notification falls back to a missing icon. xsi-drive-removable-media works. That's the first commit in the branch.

2. Ejecting from Nemo is still a problem in some cases: with some devices the drive reappears right after the eject. Nemo's sidebar eject button goes through g_mount_eject_with_operation / g_drive_eject_with_operation, which ejects the media but leaves the device powered, so the kernel re-enumerates it and it shows up again — which looks to the user as if the eject didn't work. Cinnamon's drives applet doesn't have this problem, because PlaceDeviceItem._tryRemove prefers g_drive_stop() when the drive's start-stop type is SHUTDOWN. Could Nemo's eject button do the same when the drive supports it?

3. Is there a Mint 23 install (or ISO) with unstable Cinnamon available somewhere? I'm currently testing on 6.6 with backports, which is slower and doesn't let me test the complete new version. Something ready to use would speed up my testing a lot and I think would be useful also for other users that want help to test the new version in development.

Thanks!

[cplittlfield]

This sounds like a good way of approaching it. I'm sure we'll still see complaints on the forums from people who ignore the notification, but that's on them, honestly.

One of the corollaries to Murphy's Law is, "There's no system so fool-proof that a bigger fool can't come along and break it."

[billyswong]

Personally I still wish there is a better indicator of how much data is still awaiting in cache. We get a progress bar GUI for lengthy file copy/move operation. There ought to be a progress bar GUI for lengthy "sync" operation as well. 30 seconds? 2 minutes? 1 hour? We ought to get a rough time estimate on how long one still need to wait before a drive can be unplugged (or how long until the computer can be shut down safely).

[Fantu]

A reliable estimate of the missing amount of time is not feasible, and the one visible from the host is not sufficient.
It would be useful for the thinclient project at work regarding devices connected to the thinclient, but in addition to the fact that there is an RDP connection involved, regarding the shared folder via the network, so it should be seen on two separate systems with their own cache. I have seen that even just the part in the thin client is not reliable in most cases. Even with modern SSDs, which might seem better, increasingly faster and more reliable, the opposite happens, with the memory getting worse. And on most of the customer ones (which my users use, but as would also be the case for most desktop users), which now have QLC memory, no DRAM, and only por near dynamic cache (which transforms part of the free SLC memory into cache), there are also internal disk controllers that are more unreliable than others.
And even if you try to completely disable the disk cache there are controllers that ignore these commands, I had considered completely disabling all possible caches (host and disks) to mitigate the risk of losses and reduce to zero or almost zero the time window from the end of the copy visible to the user to the possible removal but in addition to having a ridiculous speed on various SSDs I also saw that some certainly do not respect the disabling of the disk cache made by hdparm or nvme commands.

I was testing my idea from yesterday regarding the warning when the user removes devices without unmounting them first, but unfortunately, even that is more complicated than expected. I'm now testing USB drive removal in various cases to see if I can find a method that's reliable enough for all cases and doesn't give false positives. I'm afraid the part already included in Cinnamon isn't easy to use, either. I'll have to look into it further.

[cplittlfield]

This is a problem that is as old as the existence of users. Back in the floppy disk days, we had to train users to wait until the drive light finished flashing before removing the floppy from the drive. And at least they could hear the drive spinning. Thumb drives present essentially the same problem, except the risk of physical damage to the hardware is fortunately no longer an issue.

It's unfortunate that not all thumb drives have an LED to indicate that I/O is happening. That would greatly simplify the user-education part of the problem.

[billyswong]

No physical damage but now a substantial risk of the whole filesystem getting corrupted, due to the bad design of exFAT.

[Fantu]

I opened linuxmint/cinnamon#13899: it warns the user when a device is unplugged while it's still mounted, and stays silent when the device was ejected, safely removed or simply unmounted.

For anyone who wants to test Cinnamon 6.7 in development (latest tag) on Mint 23: there's no ISO yet FWIK, but I saw the alfa repo already has the unstable packages, so a test VM can be built from an Ubuntu 26.04 (resolute) image (minimal like cloud init) plus:

deb http://packages.linuxmint.com alfa main upstream import backport

Install linuxmint-keyring first. The Cinnamon 6.7.x packages are in backport, the cinnamon-core metapackage is in main, and installing ubuntu-system-adjustments handles snapd the way Mint does.

Seems enough for testing until an ISO or an easier way shows up.