Date: Sat, 5 Jan 2013 21:35:35 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: John Baldwin <john@baldwin.cx>, Jaakko Heinonen <jh@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r244585 - in head: . sys/geom/label Message-ID: <20130105203534.GF1390@garage.freebsd.pl> In-Reply-To: <50E71033.3040702@freebsd.org> References: <201212221343.qBMDhCHa086834@svn.freebsd.org> <201301041218.07804.john@baldwin.cx> <50E71033.3040702@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--pmKUVAsxJ35RhmJn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 04, 2013 at 12:24:03PM -0500, Nathan Whitehorn wrote: > On 01/04/13 12:18, John Baldwin wrote: > > On Saturday, December 22, 2012 08:43:12 AM Jaakko Heinonen wrote: > >> Author: jh > >> Date: Sat Dec 22 13:43:12 2012 > >> New Revision: 244585 > >> URL: http://svnweb.freebsd.org/changeset/base/244585 > >> > >> Log: > >> Mangle label names containing spaces, non-printable characters '%' or > >> '"'. Mangling is only done for label names read from file system > >> metadata. Encoding resembles URL encoding. For example, the space > >> character becomes %20. > >> > >> Help by: kib > >> Discussed with: imp, kib, pjd > > Ouch, mangling spaces seems unfortunate. I guess fixing the devctl pro= tocol=20 > > is too hard, and/or we can't just encode it at the protocol layer but l= eave=20 > > the actual device names untouched? OS X preserves spaces in volume nam= es and=20 > > those can be quite common on ISO images, so mangling them really does s= eem to=20 > > be a shame if we can avoid it. > > >=20 > On a related note, it would be *really* helpful if gpart labels were > actually managed by gpart. This kind of thing makes predicting the path > of a newly-labeled GPT partition extremely hard and, combined with race > conditions and synchronization issues in glabel updating in response to > changes in gpart, is why the installer doesn't use labels in fstab. I fully agree that gpart should manage GEOM providers based on labels on its own, especially that it doesn't update label by writing to underlying provider, so GEOM tasting cannot tell glabel about changes. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --pmKUVAsxJ35RhmJn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDojpYACgkQForvXbEpPzS/CgCgvmIykrzHsdOBmFVvVZAGYsS+ 054AmwTckQoNGXYZuSLWSI8/N4bsdHN6 =tvXp -----END PGP SIGNATURE----- --pmKUVAsxJ35RhmJn--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130105203534.GF1390>