Date: Sat, 24 Dec 2011 02:34:58 +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: <20111224013458.GA25515@slackbox.erewhon.net> In-Reply-To: <4EF51572.4060507@herveybayaustralia.com.au> References: <4EF4010B.5040704@herveybayaustralia.com.au> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
--7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 24, 2011 at 09:57:38AM +1000, Da Rock wrote: > > FreeBSD be default already does buffering in the VFS layer (unless you = turn > > that off). I don't think that adding more buffering would help. It migh= t even > > make matters worse. If data is buffered and not immediately written to = the USB > > stick, it will show no activity. This might even give the user a false > > impression it is finished... > That there is exactly the problem. Any way to prevent that though? Yes. Using the '-o sync' option with mount. To the best of my understanding that means that a write action will be executed immediately and that write(= 2) will not return until it is finished. > No, I hadn't considered that scenario. Thats why these lists provide a=20 > great sounding board :) It is a heck of a problem. Distributed filesystems like Coda [http://en.wikipedia.org/wiki/Coda_%28file_system%29] might offer a partial solution. But it doesn't seem like they're being widely used. > > The only sane way to handle this is for the application to get an error= from > > the next write reporting that the filesystem has disappeared. Which it = should > > then report to the user because that's the person that pulled the plug,= so to > > speak. > Man, What a mess! The real solution is to keep the light flashing until= =20 > all the data written to disk. The abovementioned -o sync option will do that for you. The price is that the write syscall will block until it is finished. This might render the application performing it unresponsive during that time. > > All the mayor players in this drama, hal, policykit and dbus are mainta= ined by > > gnome@. In practice that _might_ mean that no single person cares enoug= h to > > care and feed them. > > > Ahh. Now that may explain some things. But by your meaning are you=20 > talking about the software development itself or the developers? LOL What I mean here is that there are no dedicated maintainers for the FreeBSD ports. When that is the case, that maintainer address of a port is usually that of a relevant mailing list. That way problems with such a port at least get the attention of people with relevant interests. As for the original developers, who knows? IMNSHO their solutions look over= ly complex, but I haven't looked at the problem they try to solve because it's not a problem that bothers me. And I'm kind of allergic to desktop environments. Over the years I've tried several window managers, but I keep coming back to good old FVWM. :-) 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) --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk71LEIACgkQEnfvsMMhpyVsmACgnkXPFM7kSXSl15SFus5n0ESU JSkAn2JZTmYvxXa8xoqrAmwST647GR1K =B7I1 -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111224013458.GA25515>