Date: Fri, 04 Jan 2013 12:24:03 -0500 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: John Baldwin <john@baldwin.cx> Cc: svn-src-head@freebsd.org, Jaakko Heinonen <jh@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r244585 - in head: . sys/geom/label Message-ID: <50E71033.3040702@freebsd.org> In-Reply-To: <201301041218.07804.john@baldwin.cx> References: <201212221343.qBMDhCHa086834@svn.freebsd.org> <201301041218.07804.john@baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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 protocol > is too hard, and/or we can't just encode it at the protocol layer but leave > the actual device names untouched? OS X preserves spaces in volume names and > those can be quite common on ISO images, so mangling them really does seem to > be a shame if we can avoid it. > 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. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50E71033.3040702>