[Cc'ing the bug, not the lists.] On Thu, 2010-04-01 at 02:00 +0100, Justin B Rye wrote: > Ben Hutchings wrote: > > On Wed, 2010-03-31 at 11:45 +0100, Justin B Rye wrote: > >> In my case the name of my IOmega Zip drive changed too. Yes, I > >> only had it installed on that machine to see if it would cause > >> trouble, and it still worked as /dev/sdc1. Mind you, I imagine it > >> would be a bit of a pain assigning labels to a pile of 100MB > >> removable zip-disks if dosfslabel's still buggy (#506786). > > [...] > > > > Also reported and fixed as #559985. You're welcome. > > If it's fixed in 3.0.7-1, shouldn't dosfslabel agree with mlabel, > blkid, mount, etc on what label a vfat file system has?
If the two labels (boot sector and root directory) are inconsistent then different tools might reasonably disagree. [...] > I can use mlabel or mkdosfs to set a label that can then immediately > be used by mount, but dosfslabel still seems to be modifying some > ID-string not connected to the file system label or UUID. > > (I should probably be testing this on something less arcane.) mkdosfs and dosfslabel now write to the same two labels. I didn't test mlabel, but a quick inspection suggests that it also sets both. Note that there is no automatic mechanism to update the link in /dev/disk/by-label or the blkid cache in /etc/blkid.tab when a disk is relabelled. Lookup by label will be unreliable until these are also updated. If you can come up with a test case where dosfslabel is still doing the wrong thing (starting from a blank disk, like my test case in #559985) then I will try to fix it. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
signature.asc
Description: This is a digitally signed message part
