cross-device copying / USB improvements

[benny]

dear dragonflyers!

first of all: congratulations for such a great release!

I tried hammer and it worked without a glitch, 
and I tried USB plugging deplugging, replugging
and was impressed that the shaky USB implementation 
inherited from FreeBSD has finally been stabilized!

So this is a mixture of a bug report, a success report and
some ideas how to improve the user experience :)

I tried the following: 
- plug in a USB stick
- mount -t msdos /dev/da0s1 /mnt/usbstick
- cd  /mnt/usbstick
- ls
- unplug the stick
. ... lot of warnings, but no panic
- ls 
=> shows the old content, even if the stick isn't there any longer
- dh
=> shows /mnt/usbstick still mounted
- plug in USB stick again
=> surprise! now is da1 ! (same slot though)

here I was able to unmount the "ghost" mount on /mnt/usbstick
and to remount the "new" da1 under /mnt/usbstick again.

however, I then tried to unplug the device while copying a larger 
file to it. 
no panic, but when I did
        ls /mnt/usbstick
the system froze.

I think it could be related with the fact that ls showed the old 
files on the previous test (some caching issue?).

So I have an idea about what I would consider the best and most 
logical behaviour from a users point of view:

It would be great, if the mounted device would be "remembered" for 
a while (say 10 seconds) in a way that it:

- would be silently* umounted when the device is plugged off, 
  so ls should show nothing in the path

- would put the processes trying to access the device into a 
  waiting loop

- would be silently* remounted if the same device** is plugged in 
  again in the same slot within a certain timeframe (the 10 seconds)

- would return errors to the waiting processes after the timeout

This would be a cool way to "recover" from accidently interrupted
connections or unreliable devices.

Furthermore, for such things as copying or moving files across 
devices it would be really cool, if cp behaved like or would use 
rsync.

That would allow to recover reliably from an interrupted cp/mv 
process - without user interaction. 

If the device comes up again, only the remaining bits would be 
transfered. In the case of mv only the files that were successfully
transfered would be unlinked.

Even if the timeout has come the user could plugin the device again,
mount it again, copy again and would not start from zero (without 
needing to know tools like rsync).

If you got this far, it would be possible to show the user the 
power of the system by telling him to plug in the device again, if 
the transfer is not yet complete (maybe this could be delivered to 
desktop users as well via dbus).

Such a behaviour would really make difference compared to how the 
current linux and bsd variants do (not) handle such situations.

Just a thought. My experiences with C are very limited, so I do not 
qualify to implement such a beast, nor do I know how difficult it is
or if it might break Posix.

Whow, that one got longer than expected.

Anyway: keep up the great work!

Regards,
Benny

______________________

* with silently I mean: with a warning on the console but no 
  interruption

** I don't know if its possible, but there are usually some specific
   bits that could be read off the device (the informations shown 
   in the console or dmesg)