Project

General

Profile

Bug #1087

Updated by tuxillo almost 9 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)

Back