PolicyKit confusion

Roland Smith rsmith at xs4all.nl
Sat Dec 24 18:57:39 UTC 2011

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 and

> All valid points. What it boils down to is if you yank the power or the 
> disk during write you're screwed no matter what fancy tricks you play- 
> include hal/dbus/blah! bull crap. 

Yep. :-)

> You have tickled my imaginationings again, and I have an idea to throw 
> at the gurus on the list (including you Roland): Assuming null/void 
> computer literacy, and the use of a DE; what if one had an (can't be a 
> script can it - pointless. Thinking on the fly here...) applet? dock 
> notifier? that indicated the disk was in use and not to remove - 
> primarily for a "blinkered" user that is missing the flashing led on the 
> drive (or one missing an led)? Stays on top, flashing on the screen. Use 
> mount -d to test disk status, then lets you know that it can be removed. 
> 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 
> the write stops to the disk because the buffers need to reach a certain 
> level before write occurs, or umount. So one can mistakenly assume that 
> all is kocher and find no file when they reinsert. Files are lost that 
> way, and at the least its annoying. That can still even occur with hal 
> 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_ 
> of that then they're not worth worrying about- can't be holding their 
> hand the whole time :) Then, using devd, one can implement the 
> mount/umount scripts with a quick fsck on insertion to be sure ICIE (In 
> Case of Idiot Event).

Unmounting with devd is just triage. Umount cannot do some useful things (like
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 when
a new USB device is detected (I think you should watch for CREATE events from
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 you
want to do.

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20111224/635dce7f/attachment.pgp

More information about the freebsd-questions mailing list