Hello Andrew, Been catching up, with too little time.
On Mon, 2014-05-12 at 22:41 +1000, Andrew Greig wrote: > On Mon, 2014-05-12 at 13:27 +1000, Jason White wrote: > > Andrew Greig <[email protected]> wrote: > > > linux-sbl1:/home/andrewg # dosfsck -a -v /dev/sdb1 > > > > > > and it worked. Now I have my drive back! > > > > Excellent. Make sure that the umount command completes before you remove the > > device from the USB port, otherwise the file system will be inconsistent, > > requiring more repair. > > > > _______________________________________________ > > luv-main mailing list > > [email protected] > > http://lists.luv.asn.au/listinfo/luv-main > Thanks Jason and others, > > I see from the previous posts that the problem is caused by not using > the "Safely Remove ..." provision in the GUI. I used to run "sync" > before umount in the old days to make sure that all the writes had > completed. Obviously a moment of carelessness can cause a large amount > of pain. I will tuck the fsck command away safely i case the third > glass of whiskey kicks in unawares ;-) The "Safely Remove ..." provision will run the necessary unmount command, and any syncing. It will not relinquish the mount while there are pending writes, that is the reason for a delay. It is just good practice, the same as was sensible under old DOS systems, even if inadequately enforced, to wait for activity to cease before removing removable media. It is prudent to do a little exploring and investigation and comprehend what is happening, it prevents these foreseeable problems and associated grief. There will be some script or the like relating to the automounting, and when mounted, it will appear in the /etc/mtab file. As to a little hiccup with unmounting, that will block if something has an open file or directory on the device filesystem. > Cheers > Andrew Regards, Mark Trickett _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
