| Summary: | async behaviour during file copy to a removable device is confusing. | ||
|---|---|---|---|
| Product: | [Unmaintained] kio | Reporter: | Davide Bettio <davide.bettio> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | critical | CC: | adawit, andreas_nordal_4, bjoern, chalkerx, christopher.m.braeuer, hakan, jramirez.uy, kikoloche, lumania, mail, nate, phlogi1, sylvain.gueniot, vortex |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Davide Bettio
2009-06-03 00:18:15 UTC
This bug may lead some users to data loss. I've changed priority to critical because data loss is a critical bug. This is a kernel behavior, not a behavior of kio_file. You can use the -o sync option in mount to mount the device in synchronous mode, although that will be quite slow. This cannot lead to data loss since you are *not* supposed to unplug the device before you properly unmount it. Unmount takes care to write the remaining data on the device and does not return until everything is written properly. We can open the new file (during a copy job) with O_SYNC.
>This cannot lead to data loss since you are *not* supposed to
>unplug the device before you properly unmount it.
Are users supposed to wait 3/4 minutes before their usb devices get unmounted?
Wouldn't it be possible (and actually pretty easy) to simply issue a sync (like with the command-line tool 'sync') before displaying the copy job as "completed" when writing to a removable device. That way the user could be sure that the file has been written once the copy job completes. Of course you should properly unmount a device before unplugging but I think it would be more rational to only show a copy job as "completed" when the data was actually written - at least on a removable device. Especially switchers from Microsoft Windows or novices are not used to unmounting a device before unplugging. Even experienced users can easily forget to unmount a USB stick before unplugging. This couldn't happen as easily if there was still a copy job visible on your desktop. I think this is a related bug: https://bugs.kde.org/show_bug.cgi?id=192598 *** Bug 188978 has been marked as a duplicate of this bug. *** I have the impression this is highly improved with 4.3. I just made a copy and the progress bar freezes at the end of the copy of each file and the copy won't be marked as done before it actually is. Well, not for me. Just copied a 200 MB file to usb - and had to wait approximatly 20 seconds for the unmount to complete although the job was finished. Anyway, why should a removable stick NOT beeing mounted synchronously? Normal usage is to copy files to or read files from it - there is no advantage of asynchronous mode there. It is something different when you have your system running from usb - then you want it to be asynchronous. But I cannot see why someone who uses device manager to mount a stick needs asynchronous file transfer. FYI: http://lkml.indiana.edu/hypermail/linux/kernel/0505.1/1249.html From my past experience (no recent numbers though), sync copying was much slower than async + unmount. Possible patch on review board: http://reviewboard.kde.org/r/2690 Unmounting a removable device always guarantees that all files are completely written to the device AND you are not supposed to remove a device without unmounting it. OTOH, Big files are always written out to the devices at the moment of copy request. Only small files wait in buffer and written instantly to the flash media upon unmount. I fail to see the issue here. (In reply to comment #12) >> I fail to see the issue here. You have to be kidding me! I had to teach my 4-years old son to wait unntil 'the light is off' (yeah, I had to say that), because on windows he has no problem umounting the pendrive after the copy dialog finished, but with KDE is not the same: When he says: "Dad! It's finished, look at the progress bar!".. I have to explain "No son, it is not finished yet, juist wait until the light turns off".. I fail to see this is ok. PD: I known this comment has more than a year old, but the bug is still alive and healthy! > Unmounting a removable device always guarantees that all files are completely > written to the device AND you are not supposed to remove a device without > unmounting it. > > OTOH, Big files are always written out to the devices at the moment of copy > request. Only small files wait in buffer and written instantly to the flash > media upon unmount. > > I fail to see the issue here. Can this be fixed with: 1) A «busy» indicator near the usb drives in dolphin places / devices plasmoid? 2) Another, «syncing» progress bar when you press unmount? Currently unmount does not give the right/any/understandable feedback while waiting for sync being completed. The question is: is it possible to get the progress of the sync operation? Is it possible to tell if sync is being done at the current moment («busy» indicator)? s/if sync is being done/if sync is being done or is planned/ IMHO, with the increasing presence of the led-less flash drives and hard disks, a syncing indicator becomes extremely necessary. IIRC, Ubuntu is doing this for a long time (I remember "please wait I'm writing data to your disk" dialog) and it is very useful for everyone. Also while may not be directly relevant, I want to say that making a user worry less about operating a computer correctly greatly improves the user experience regardless of the level of the knowledge of the user (for example, I'm a developer yet want this indicator). Don't forget the "flush" mount option. It should reduce the asyncness, maybe to an acceptible level? Bug 273792 wants to mount with flush by default. KDE now has a "please wait" notification in the USB widget (via a spinning disk in the place of the eject button during sync) and dolphin doesn't change mounted symbol until sync completes. Also don't forget that, 99.95% of the USB flash drives eject properly after unmount so, your device is safe to remove when it disappears from USB widget / dolphin. The proposed patch is not required anymore. Nevertheless, the patch runs afoul of the many optimizations and concepts of the Linux storage subsystem. IMHO, the solution addresses the problem from the wrong aspect. *** Bug 274141 has been marked as a duplicate of this bug. *** *** Bug 187511 has been marked as a duplicate of this bug. *** *** Bug 274747 has been marked as a duplicate of this bug. *** Is this still relevant or applicable with KDE Frameworks 5.45 and Plasma 5.12? Is this still relevant or applicable with KDE Frameworks 5.45 and Plasma 5.12? Currently KDE does not allow to unmount a drive while a foreground file transfer or a background sync is in progress as far as I observed. I find this behavior adequate, however I think my opinion alone is not sufficient to close this bug. From my point of view this bug can be closed. Agreed. No risk of data loss anymore. Great, thanks! |