Bug 148881 - [libdisk] [patch] libdisk emits errors w/ disks that contain spaces in labels
Summary: [libdisk] [patch] libdisk emits errors w/ disks that contain spaces in labels
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.1-PRERELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
Depends on:
Reported: 2010-07-23 23:20 UTC by Jeremy Chadwick
Modified: 2018-01-03 05:16 UTC (History)
0 users

See Also:

file.diff (563 bytes, patch)
2010-07-23 23:20 UTC, Jeremy Chadwick
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Chadwick 2010-07-23 23:20:06 UTC
	libdisk(3)'s Int_Open_Disk() function makes some bad assumptions
	about the syntax of the lines come from sysctl kern.geom.conftxt
	(passed in via sysinstall).

	Disks, slices, or partitions which have spaces in their label
	names -- such as FAT-formatted USB flash drives with spaces in
	their volume name, or anything glabel'd -- will cause libdisk
	to spit out an error similar to the below.  Use of dialog
	in sysinstall hides portions of the error string:

	Int_Open_Disk(da1): can't parse length 'V100W' in line 3 (r='V100W')

	In this situation, the disk da1 was a FAT32-formatted USB flash
	drive with a volume name of "HP V100W".  kern.geom.conftxt showed:

0 DISK da1 4009754624 512 hd 255 sc 63
1 PART da1s1 4009722368 512 i 1 o 32256 ty !12 xs MBR xt 12
2 LABEL msdosfs/HP V100W 4009722368 512 i 0 o 0

Fix: I've spent the past 6-7 hours going over the libdisk(3) code's
	parser, and determined that (probably) the easiest way to deal
	with this is to ignore LABEL lines altogether.  There is probably
	a cleaner way to deal with this, such as using libgeom(3) (which I
	did try but the API is severely lacking in documentation), but
	this is what I came up with.  This should be thoroughly analysed
	before being considered for commit.

	Also, I want to point out that the inline comment for "t"
	assignment doesn't appear to be correct (see above example, re: MBR).
	This makes me wonder if we have further parser problems in this
	library (maybe this could explain PR 140972)?
How-To-Repeat: 	glabel create "some label" /dev/da0s1a
Comment 1 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:28 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped