From owner-freebsd-geom@FreeBSD.ORG Thu Aug 19 15:50:03 2010 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F7751065698 for ; Thu, 19 Aug 2010 15:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6044F8FC0A for ; Thu, 19 Aug 2010 15:50:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o7JFo39F090004 for ; Thu, 19 Aug 2010 15:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o7JFo3sD090003; Thu, 19 Aug 2010 15:50:03 GMT (envelope-from gnats) Date: Thu, 19 Aug 2010 15:50:03 GMT Message-Id: <201008191550.o7JFo3sD090003@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: jhell Cc: Subject: Re: kern/149762: volume labels with rogue characters X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jhell List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 15:50:03 -0000 The following reply was made to PR kern/149762; it has been noted by GNATS. From: jhell To: Oliver Fromme 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 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