Fwd: [KDE Usability] Users cannot find where to "safely remove" USB sticks from Device Notifier plasmoid.

Sun Apr 11 17:46:14 UTC 2010

Hello Ubuntu developers,

there currently is an interesting thread on KDE-usability about USB
drives and the »safely remove« function. This being relevant not only
to KDE but to operating systems in general, I thought it would be a
good idea to share.

We are discussing about how to get rid of the need
to safely remove a UBS drive altogether by adapting the behavior of
download managers (if that is possible).

The complete thread: http://lists.kde.org/?l=kde-usability&t=127039246200001

A message discussing possible implementations:

---------- Forwarded message ----------
From: Peter Grasch <grasch at simon-listens.org>
Date: 11 April 2010 15:47
Subject: Re: [KDE Usability] Users cannot find where to "safely
remove" USB sticks from Device Notifier plasmoid.
To: KDE Usability Project <kde-usability at kde.org>

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.
> >>
> > On 11 April 2010 14:24, Jan-Christoph Borchardt <jan at inquata.com> wrote:
> >> 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.

> > On 11 April 2010 14:24, Jan-Christoph Borchardt <jan at inquata.com> wrote:
> >> 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 at kde.org
https://mail.kde.org/mailman/listinfo/kde-usability