Re: USB keys to the gate of madness

[prev] [thread] [next] [lurker] [Date index for 2006/10/28]

From: jrodman
Subject: Re: USB keys to the gate of madness
Date: 22:37 on 28 Oct 2006
On Sat, Oct 28, 2006 at 09:22:30PM +0200, A. Pagaltzis wrote:
> * Yossi Kreinin <yossi.kreinin@xxxxxxxx.xxx> [2006-10-28 13:15]:
> > WHY do I have to manually mount/umount these fucking things,
> > and why is silently corrupting my files a reasonable way to
> > enforce this wonderful policy?
> 
> The alternative is to mount them with synchronous data writing.
> Which they are (at least used to be) too slow to do usefully if
> you do bulk transfers of any size; you'll be sitting around
> waiting for files to finish copying that would normally be
> transferred in the background. 

As a bash user, I solve this pretty readily with 

  cp from to &

Or really it ends up being

  script &

I suppose there are situations where this is insufficient but it covers
all of mine, given that I use a usb stick for data transport, not a
place to manipulate things directly.

This doesn't really excuse that by default the system is dangerous, of
course, as pointed out by Yossi.


As for the filesystem format, I think if you're going to be dumb enough
to rely on reimplementations of disk formats for data interachange,
you'd sure as hell pick one stupid enough that everyone can implement
without _too_ many errors.  It's quite possible to implement FAT without
a lot of code.  If it wsan't for the long filenames idiocy, it would
downright straighforward.

The problem I forsee with some kind of file manipulation API (microsoft
has one for music players, i forget the name just now), is that it is
going to be both a library design and a software implementation on
device.  Both of them are going to be hateful, you can be sure.  The
camera-extended music player access api is pretty awful as is.
There's stuff above here

Generated at 20:01 on 07 Nov 2006 by mariachi 0.52