Skip site navigation (1)Skip section navigation (2)
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>