Date: Sat, 24 Dec 2011 19:57:05 +0100 From: Roland Smith <rsmith@xs4all.nl> To: Da Rock <freebsd-questions@herveybayaustralia.com.au> Cc: freebsd-questions@freebsd.org Subject: Re: PolicyKit confusion Message-ID: <20111224185705.GB48478@slackbox.erewhon.net> In-Reply-To: <4EF5C945.5070800@herveybayaustralia.com.au> References: <20111223142252.GC660@slackbox.erewhon.net> <4EF49DDB.2060609@herveybayaustralia.com.au> <20111223173139.GA7648@slackbox.erewhon.net> <4EF4FAAA.1020603@herveybayaustralia.com.au> <20111223232102.GA20961@slackbox.erewhon.net> <4EF51572.4060507@herveybayaustralia.com.au> <20111224013458.GA25515@slackbox.erewhon.net> <4EF53795.1090409@herveybayaustralia.com.au> <20111224120849.GA40495@slackbox.erewhon.net> <4EF5C945.5070800@herveybayaustralia.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
--IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 24, 2011 at 10:44:53PM +1000, Da Rock wrote: > > And yes, that will block write calls until they're truely done. > You said that was slower too. A bit. But I think it is a good trade-off for filesystems on USB disks. It certainly circumvents a whole lot of problems with filesystem consistency a= nd stuff. > All valid points. What it boils down to is if you yank the power or the= =20 > disk during write you're screwed no matter what fancy tricks you play-=20 > include hal/dbus/blah! bull crap.=20 Yep. :-) > You have tickled my imaginationings again, and I have an idea to throw=20 > at the gurus on the list (including you Roland): Assuming null/void=20 > computer literacy, and the use of a DE; what if one had an (can't be a=20 > script can it - pointless. Thinking on the fly here...) applet? dock=20 > notifier? that indicated the disk was in use and not to remove -=20 > primarily for a "blinkered" user that is missing the flashing led on the= =20 > drive (or one missing an led)? Stays on top, flashing on the screen. Use= =20 > mount -d to test disk status, then lets you know that it can be removed.= =20 > I still have to test this, but I thought I'd throw it out there. Just add a button to that applet that is called "eject" or "remove" (or something like that) and have that unmount the fs in question. Then put up a dialog or notification saying "The USB device can be removed" or something = of that nature. That's basically what windows does, and it works well enough. > Basically, the situation (that I have found myself in numerous times) is= =20 > the write stops to the disk because the buffers need to reach a certain= =20 > level before write occurs, or umount. So one can mistakenly assume that= =20 > all is kocher and find no file when they reinsert. Files are lost that=20 > way, and at the least its annoying. That can still even occur with hal=20 > and blah blah blah. I'd still advocate mounting these discs with '-o sync'. Yes, it is a bit slower but it prevents a lot of trouble and is a lot easier. > Is this feasible though? If the user still can't pay attention to _all_= =20 > of that then they're not worth worrying about- can't be holding their=20 > hand the whole time :) Then, using devd, one can implement the=20 > mount/umount scripts with a quick fsck on insertion to be sure ICIE (In= =20 > Case of Idiot Event). Unmounting with devd is just triage. Umount cannot do some useful things (l= ike flushing buffers) if the disk has already been removed! It can only remove = the mount so you won't get trouble when the user sticks the device back in. And on a 4 GiB thumbdrive, I doubt an fsck is going to be really quick! Remember that the drive will be basically unusable when the check is in progress. I could imagine getting all kinds of complaints from users in the shape of "I plugged it in and it doesn't work". It should not be too difficult to write a script that is called from devd w= hen a new USB device is detected (I think you should watch for CREATE events fr= om the CDEV subsystem of the DEVFS system). I think it should check /dev first for new disk labels (/dev/msdosfs or /dev/ufs) and second for for disk devices, and try and mount them using appropriate filesystems under /mnt/$USER/$NUM (the latter because there might be more than one USB device= in use). Optionally it could also launch a new instance or new window of the user's file manager, depending on how much hand-holding and customization y= ou want to do. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --IiVenqGWf+H9Y6IX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk72IIEACgkQEnfvsMMhpyXJwACgknTmtF7aOcTgWNc10DTQMe6O BuEAnicCleS5/Fs+KWxgUQjXFdXNeH0b =6kqD -----END PGP SIGNATURE----- --IiVenqGWf+H9Y6IX--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111224185705.GB48478>