From owner-freebsd-questions@FreeBSD.ORG Sat Dec 24 18:57:39 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9120E1065672 for ; Sat, 24 Dec 2011 18:57:39 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by mx1.freebsd.org (Postfix) with ESMTP id 20CC68FC12 for ; Sat, 24 Dec 2011 18:57:38 +0000 (UTC) Received: from slackbox.erewhon.net (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id pBOIv6ka057518; Sat, 24 Dec 2011 19:57:06 +0100 (CET) (envelope-from rsmith@xs4all.nl) Received: by slackbox.erewhon.net (Postfix, from userid 1001) id DD9B6BACF; Sat, 24 Dec 2011 19:57:05 +0100 (CET) Date: Sat, 24 Dec 2011 19:57:05 +0100 From: Roland Smith To: Da Rock Message-ID: <20111224185705.GB48478@slackbox.erewhon.net> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IiVenqGWf+H9Y6IX" Content-Disposition: inline In-Reply-To: <4EF5C945.5070800@herveybayaustralia.com.au> X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-questions@freebsd.org Subject: Re: PolicyKit confusion X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 18:57:39 -0000 --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--