Bug #1087
Updated by tuxillo over 11 years ago
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)