[prev] [thread] [next] [lurker] [Date index for 2006/10/28]
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