[frameworks-solid] [Bug 453894] Disk can be ejected while files on it are still being read from or written to
https://bugs.kde.org/show_bug.cgi?id=453894 Nate Graham changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Nate Graham --- OK cool. *** This bug has been marked as a duplicate of bug 453890 *** -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 453894] Disk can be ejected while files on it are still being read from or written to
https://bugs.kde.org/show_bug.cgi?id=453894 --- Comment #11 from Julius R. --- (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. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 453894] Disk can be ejected while files on it are still being read from or written to
https://bugs.kde.org/show_bug.cgi?id=453894 --- Comment #10 from Nate Graham --- 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? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 453894] Disk can be ejected while files on it are still being read from or written to
https://bugs.kde.org/show_bug.cgi?id=453894 --- Comment #9 from Julius R. --- (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. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 453894] Disk can be ejected while files on it are still being read from or written to
https://bugs.kde.org/show_bug.cgi?id=453894 --- Comment #8 from Nate Graham --- > 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. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 453894] Disk can be ejected while files on it are still being read from or written to
https://bugs.kde.org/show_bug.cgi?id=453894 --- Comment #7 from Julius R. --- 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! -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 453894] Disk can be ejected while files on it are still being read from or written to
https://bugs.kde.org/show_bug.cgi?id=453894 Nate Graham changed: What|Removed |Added Summary|Eject Symbol next to mount |Disk can be ejected while |drives can lead to |files on it are still being |unexpected behaviour. |read from or written to Component|Places |general Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |CONFIRMED Assignee|kio-bugs-n...@kde.org |lu...@kde.org Product|frameworks-kio |frameworks-solid Ever confirmed|0 |1 CC||k...@privat.broulik.de --- Comment #6 from Nate Graham --- 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. -- You are receiving this mail because: You are watching all bug changes.
