[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: [KDE Usability] Users cannot find where to "safely remove" USB
From:       Peter Grasch <grasch () simon-listens ! org>
Date:       2010-04-11 13:47:23
Message-ID: 201004111547.23387.grasch () simon-listens ! org
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]