From kde-usability Sun Apr 11 13:47:23 2010 From: Peter Grasch Date: Sun, 11 Apr 2010 13:47:23 +0000 To: kde-usability Subject: Re: [KDE Usability] Users cannot find where to "safely remove" USB Message-Id: <201004111547.23387.grasch () simon-listens ! org> X-MARC-Message: https://marc.info/?l=kde-usability&m=127099371330049 Hi! I am not really a member of KDE usability so I hope it's ok if I comment here but I think this is a great thread :) Disclaimer: I have no HCI degree and know extremely little about the implementation of all this. I am speaking strictly as a user. On Sunday 11 April 2010 15:17:56 yahoo-pier_andreit wrote: > Dotan Cohen wrote: > >>> Tell me, in detail, how such a system would work behind the scenes. If > >>> you are detailed enough, someone will code it. > >> > >> Users can pull out USB drives at will. If there was no writing process > >> currently taking place, nothing happens – the device is safely > >> removed. Many people do that anyway because they are either annoyed > >> about the work to »safely remove« a drive or they simply do not know > >> there is an option for that. > > > > So far, this sounds like you recommend a "sync" after every read / > > write command from / to the drive. This is the easy part. I couldn't agree more. But I'd take this a step further. Why not make writes on removable media synchronous? In my experience this would instantly fix more than 90 % of all problems with pulling out the USB disc too early. (I don't know how often I had people asking me why I didn't just pull out the USB key after I copied some files onto it when "safely removing" took long after the copy had already "finished") Async. writes make very little sense on USB keys (IMHO). For power users who want all the performance they can get, they could disable it anyways. > >> Only if there is some kind of problem, the user gets notified to > >> reinsert the stick and the system is able to continue from that point > >> on. Download managers can handle that, why not operating systems? > > > > How would that work? Store the file in /tmp until it is successfully > > written? Give details. > > Oh I don't know, but as Jan-cristoph say download manager do it safely, > why cannot operating system do it? > but about /tmp I think not, may be not enough space in the hd where /tmp > lies, another problem is that could appear slower copy files in/from USB > removable compared to other OS's which uses safely remove. Why not integrate some sort of "retry" functionality into KIO Jobs? Its not perfect but consider this use case: The user wants to copy a directory "foo" containing three files: "a", "b", "c". During the copy operation ("a" has already been copied, "b" was currently beeing copied, "c" has not yet been copied) the device is disconnected. Dolphin could then display an error: "The transfer was not yet completed and not all files were may have been transferred completely. To retry please re-connect the device and press 'retry'." When re-inserting the device (maybe a UID check if its the same), the same copy job is run again, encountering the previously written files. As always KDE will display the needed confirmation dialogs (overwrite / skip / etc.) dialogs. Its not perfect and the implementation might be harder than it looks at the first glance (for example when the KIO Jobs has more complicated sources like non-sequential devices) but it would be great if KDE could ditch the "safely remove" button in the long haul... On Sunday 11 April 2010 15:30:23 Dotan Cohen wrote: > Because nobody has come up with a safe, reliable way of doing it. HTTP > does not natively support resumed downloads, someone had to get > creative there. So be creative, or see how your favourite download > manager does it. Well the easiest way to do it is certainly to seek to the end of the partially written file and compare the last couple of thousands bytes to the same portion in the source file. Of course this is a very quick and dirty check but it would be incredibly fast and with a few safety precautions (maybe a few other randomly selected portions of the file that are compared) should be sufficient for comparing files with the same file names. In doubt, the Job could display a dialog asking the user if it is possible that those are in fact the same file and if KDE should "complete the transfer" or something similar. I don't think that users would be confused by such messages... Greetings, Peter -- Peter Grasch SIMON listens e.V. http://simon-listens.org _______________________________________________ kde-usability mailing list kde-usability@kde.org https://mail.kde.org/mailman/listinfo/kde-usability