Date: Thu, 19 Aug 2010 15:50:03 GMT From: jhell <jhell@DataIX.net> To: freebsd-geom@FreeBSD.org Subject: Re: kern/149762: volume labels with rogue characters Message-ID: <201008191550.o7JFo3sD090003@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/149762; it has been noted by GNATS.
From: jhell <jhell@DataIX.net>
To: Oliver Fromme <olli@lurza.secnetix.de>
Cc: bug-followup@freebsd.org
Subject: Re: kern/149762: volume labels with rogue characters
Date: Thu, 19 Aug 2010 11:42:32 -0400
On 08/19/2010 07:29, Oliver Fromme wrote:
> jhell <jhell@dataix.net> wrote:
> > This is a hack, something that you would commonly find in Linux code and
> > is neither a proper or viable workaround for the naming of labels.
> >
> > Instead, using glabel(8) the admin/user can create a local label to
> > FreeBSD that does not change the original nor does it carry over to any
> > other OS that does not understand geom_label's.
>
> There are cases were you cannot create a permanent label
> with glabel. For example, there are quite a lot of USB
> devices that insist on having their memory formatted with
> their own firmware only, destroying any other labels.
> I own an mp3 player (Medion) that behaves like this.
> The submitter mentioned a digital camera (Nikon, I think)
> in a previous thread.
>
> How do you suggest to solve the problem for those cases?
>
> > Stripping characters no matter what they are with a sysctl is overkill
> > and does not scale well, all the while - presenting false information to
> > the user.
>
> I don't think there is a scalability issue, because it is
> only done once when a device is attached. On the other
> hand, maybe the patch should be changed so it doesn't
> touch the name at all when the sysctl is 0, so the default
> behaviour would be no different from what we have today.
If this is the case then why adapt geom_label at all ? why not instead
go straight for the culprit "devfs/devd" and add a sysctl for stripping
what needs to be stripped ?. This way it is distinct to /dev and can be
done on the system-wide basis and/or focused on particular pieces of the
system like geom_label. This is more of what I meant by scalable.
>
> > I would highly advise against this. If the user does not like
> > the label that appears in msdosfs/{LABEL} then they are free to change
> > that at their own will.
>
> Unfortunately they are subject to the will of their devices,
> see above. And if the device's own label contains a space
> (the Nikon camera mentioned above does), it cannot be used
> as-is in /etc/fstab.
That is understandable but to adjust the code to fit a few edge cases
like this IMO just feels wrong, remember this is only my opinion in this
case.
>
> I think a similar problem occurs with the volume names of
> CD-ROMs and DVD-ROMs, which contain spaces quite often,
> and you cannot glabel them. But I haven't looked deeply
> into this, maybe it's not an issue.
>
> (Does FreeBSD even support mounting CDs by their volume
> name, like Solaris does? I've never tried, but it would
> come in handy, because I have a clip art CD that I use
> every now and then, and I never remember whether it's in
> drive cd0 or cd1 currently ...)
Yes it does.
I usually turn these off for client systems as I find them very unneeded
and duplicate cases that can cause hell on hald(8). Design flaw of
hald(8)? no but we introduced it.
kern.geom.label.ext2fs.enable=0
kern.geom.label.iso9660.enable=0
kern.geom.label.msdosfs.enable=0
kern.geom.label.ntfs.enable=0
kern.geom.label.reiserfs.enable=0
kern.geom.label.ufs.enable=0
kern.geom.label.ufsid.enable=0
kern.geom.label.gptid.enable=0
kern.geom.label.gpt.enable=0
>
> > I see presenting the label as it is to the user
> > ``important''.
>
> Uhm ... it is not my impression that the names of nodes
> in /dev are intended to present accurate "external"
> information to the user. I always thought that the
> purpose of /dev is an interface between userland software
> and drivers, and that users shouldn't have to deal with
> /dev at all during "normal operations". Am I wrong?
No you are not wrong. But in the case of first introduction of the
device and the use of fstab(5) being mentioned already, the user has to
interact with /dev right ?
>
> I mean, there are commands to display the atual labels if
> you need to see them (and I don't mean "ls /dev/...").
>
Right I agree with this to an extent that the hypothetical user should
not have to drop back to a manual page to find out how to get the
original information of the device.
Regards,
--
jhell,v
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008191550.o7JFo3sD090003>