On Monday 12 April 2010 01:03, Markus wrote:
> Am Sonntag 11 April 2010 09:40:53 schrieb Peter:
> > A modern system therefore will merely notify the user that the stick was
> > 'cleanly removed', or not, as the case may be. Dirty sticks may be
> > cleaned by simply reinserting them in the proper computer. Sticks may be
> > automatically mounted at designated places, so users need never do that
> > either (although they can).
> >
> > This, imho, is a flaw in current operating system design, not a usability
> > issue.
>
> Well, actually this is AFAIK a flaw in file system design. IIRC when
> (classic) iPods still used HFS+ (the Mac file system), users could pull the
> plug at any time during sync. When the plug was reinserted, syncing
> continued. Then Apple targeted Windows users and switched all iPods to
> FAT32 and that benefit vanished for all users, including Mac users.
>
> I think, if there was a feasible way to achieve the old experience with
> FAT32, Apple would've modified Mac OS to get this feature -- if only to
> have additional argument why Mac OS is better than Windows...

So there is evidence that the problem is not a KDE one, although KDE may still 
provide a work-around.

The file format sticks use may contribute to the problem, but I don't think it 
is the only one. The issue, imho, is in two parts: the stick must be 
writeable with clean/dirty info, and, the system must be able to sync based 
on the info read from the stick. 

Most file systems are designed to read/write data, so adding info to the stick 
is relatively easy. The hard part is getting the system to read and sync 
properly. More importantly, the system needs to check whether it was the 
computer the stick was removed from, and not some other.

I'm curious to know whether KDE could read/write the stick when it is 
inserted, since it must be informed in order to change the device's icon etc. 
This will at least address the first part: can the stick be correctly marked?

This will, of course, mean KDE must temporarily mount and open a file, but the 
delay should go unnoticed. Or, perhaps, access an unused part of the boot 
sector (dangerous, but faster).

Regards,

Peter
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability