Bug 453894 - Disk can be ejected while files on it are still being read from or written to
Summary: Disk can be ejected while files on it are still being read from or written to
Status: RESOLVED DUPLICATE of bug 453890
Alias: None
Product: frameworks-solid
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.93.0
Platform: Manjaro Linux
: NOR major
Target Milestone: ---
Assignee: Lukáš Tinkl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-05-16 14:28 UTC by Julius R.
Modified: 2022-05-18 16:50 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Julius R. 2022-05-16 14:28:16 UTC
Hi everyone,
I don't know who and why this has been green flagged, but the newest addition of an eject button next to mounted drives (not USB drives, hard drives! Meaning all network folders, all additional mounted volumes!) is an terrible idea! It is really mindbuffling dangerous. A normal user - like my mom - could (has) accidently click on them way, way to easily. For there is no dialogue of confirmation (!), the drive gets onhooked immediately. An ongoing copy process could lead to data corruption. Running services relying on the drive could lead to data corruption. Imagine for example having a syncing software running. Like synology drive? When the drive is unmounted without shutting it down beforehand, the syncing software might (I know it does, it is badly written) interpret the missing drive as deleted files, meaning, it deletes the files on the synced target.
And so on and so on.

This should definetly not be there for hard drives and if, it needs a confirmation for unmounts.

Cheers and have a nice day.
Comment 1 Nate Graham 2022-05-16 18:12:51 UTC
> the drive gets onhooked immediately. An ongoing copy process could lead to data corruption. Running services relying on the drive could lead to data corruption.

That's not supposed to happen. When I copy a large file to an external drive and then click on the Eject button, Dolphin shows an error message saying, "One or more files on this device are opened in application "dolphin"."

Does that not happen when you try this? Can you attach a screen recording that shows the issue happening?
Comment 2 Julius R. 2022-05-16 18:24:57 UTC
Hi Nate, you are right, when the file process is handled by plasma, this does not pose a problem. False assumption by me, sorry.
The other problems remain however: Whenever a service or third party application depends on the mounted drive "being there", an accidental unmount can lead to serious problems.
Comment 3 Nate Graham 2022-05-16 18:40:50 UTC
Are you 100% sure of that? Did it happen to you?
Comment 4 Julius R. 2022-05-16 18:52:58 UTC
Yes, it did. This is a freak case, but when using synology drive client on a mounted drive (synchronisation tool for a local or remote NAS) and the local source gets unmounted while the app is running, it acknowledges the emptiness as a command to delete all files at target. 
This is, obviously, unwanted behaviour and a critical bug within the synology software. But I stand by my point, a locally mounted drives should not be dismounted without confirmation.
It must not always be critical, it could also be simply inconvenient. Imagine this use case: A user has an encrypted drive. For dual-boot purposes, this is done with veracrypt. The decrypted drive will now appear as mounted device. On this drive,  the user stores config files from mozilla, work files, sensible settings from other programs etc etc. If this drive can be randomly unmounted by accidently clicking on it in the file explorer (dolphin), that can be quite an annoyance...
Comment 5 Julius R. 2022-05-16 18:58:35 UTC
Let me rephrase that: 
Unmounting drives with one click, is convenient - if the user knows what he is doing. For example, by triggering the context menu.
Unmounting drives with one click by accidently (!) clicking on a pictogram, can be a problem.
Imho :)
Comment 6 Nate Graham 2022-05-16 19:13:23 UTC
Thanks for the info!

If we asked for confirmation before unmounting, it would drive people crazy. If we did it anyway and gave the the dialog a "don't ask again" checkbox to avoid driving people crazy, everyone would click it and then become vulnerable to the issue you're describing.

I agree with you that the app in question has a critical data loss bug that should be fixed, but in addition, if the user attempts to unomunt a disk while files on it are being accessed, the system is supposed to notice this and block it. And that works for me. If it's not working in this case, that's a bug that we can and should fix so that one-click unmounting isn't dangerous. :) That's the path forward here.
Comment 7 Julius R. 2022-05-16 20:18:05 UTC
Thanks for the clarification. I do believe, this bug report should be closed as resolved now?
Reason: As you described KDE is aware of file operations and disallows unmounting (as it should), when there are operations running (like copying). My point is a different one: That it can lead to unwanted behaviour, if a mounted drive gets unmounted accidently, if other software relies on it. For example, a browser does not start anymore, when the config files have been stored on that particular drive, which is mounted at boot. There is also no file-operation in my case of data-loss, which was a critical bug in synologys software (I circumvented this now with a little script, that kills the synology client, whenever it detects, that the drive is no longer mounted).

So, summarized
a) There is no way for the system to anticipate the complications described above. They just happen and are not related to file operations.
b) When the majority of users is fine with the eject icon luring dangerously over every mounted drive, folder and device - then that is the way it is and it should stay. :)

Thanks Nate!
Comment 8 Nate Graham 2022-05-17 14:24:55 UTC
> As you described KDE is aware of file operations and disallows unmounting (as it should),
> when there are operations running (like copying). My point is a different one: That it can lead
> to unwanted behaviour, if a mounted drive gets unmounted accidently, if other software
> relies on it.
That shouldn't happen. Since the system is aware of open files, if you try to unmount a disk that has open files on it, it's supposed to prevent that from happening. If that didn't work and you were able to unmount a disk with open files, that's a bug. That's the bug that we're tracking with this Bugzilla ticket.
Comment 9 Julius R. 2022-05-17 18:29:30 UTC
(In reply to Nate Graham from comment #8)
> That shouldn't happen. Since the system is aware of open files, if you try
> to unmount a disk that has open files on it, it's supposed to prevent that
> from happening. If that didn't work and you were able to unmount a disk with
> open files, that's a bug. That's the bug that we're tracking with this
> Bugzilla ticket.

More misunderstandings :) The system is surley aware of open files, there is no bug with that. It can not anticipate that files "might" be opened or accessed soon...
The inconvenience I describe happens (apart from the critical synology bug), when files are not available at a specific time, due to accidently unmounting the drive. If, to give that example again, config files (the user profile) for e.g. Firefox are stored on an encrypted drive (or in a company on a network drive) - and that drive is not available due to a user accidently and unknowingly unmounting drives, then the browser gives an error: It simply can not find the user profile. There is neither file activity before or after, there are no open file activities.
The problem described is btw exactly, what happenend to my mum: She accidently unmounted the drive and then didn't know, what to do.

Due to the small little change of adding an unmount icon, I - personally - experienced a critical data loss (I had backups, of course). This was a bug of a third party software, that no one could foresee. On the other hand, I also had problems with a less experienced user, that did not understand the concept of mounting and unmounting - at all. Therefore, I stand by my suggestion: Network Drives and Encrypted Drives should never ever have a "quick-unmount-icon". Unlike usb flash drives (which are used only temporarily), network drives and (un)encrypted drives are (in most use cases) an integrated part of the users workflow. They need to be accessible at all times, from boot till shutdown.
Comment 10 Nate Graham 2022-05-18 16:41:29 UTC
No, we can't guess the future, but we can prevent ejecting a disk that still has files on it being actively read or written to.

Are you saying that this happened on a disk that did *not* have any files on it being read or written at the moment you clicked the eject button?

Are you saying you want what's being requested in Bug 453890?
Comment 11 Julius R. 2022-05-18 16:42:54 UTC
(In reply to Nate Graham from comment #10)
> No, we can't guess the future, but we can prevent ejecting a disk that still
> has files on it being actively read or written to.
> 
> Are you saying that this happened on a disk that did *not* have any files on
> it being read or written at the moment you clicked the eject button?
> 
> Are you saying you want what's being requested in Bug 453890?

Yes. Sorry for the hassle. This is a duplicate of 453890.
Comment 12 Nate Graham 2022-05-18 16:50:52 UTC
OK cool.

*** This bug has been marked as a duplicate of bug 453890 ***