reassign 506786 libvolume-id0
tags 506786 +moreinfo
thanks
Sam Morris wrote:
> I've tried running dosfslabel to change the label of a vfat filesystem. This
> seemed to work:
>
> # /sbin/dosfslabel /dev/sda1
> sam
correct.
> However, the change was not picked up by HAL. On investigation, it seems that
> this is because libvolume-id0 still sees the label as 'UDISK 2.0.
which is definitely not a problem with dosfstools here (if you want to
make sure and reproduce it yourself, you can zero an usb stick (or a
loopmounted image) first, and then run dosfslabel on it and check the
content).
> The string 'sam16' does appear at the top of the device:
>
> 00000000 eb 58 90 4d 53 57 49 4e 34 2e 31 00 02 80 d0 10 |.X.MSWIN4.1.....|
> 00000010 02 00 00 00 00 f8 00 00 3f 00 80 00 80 1f 00 00 |........?.......|
> 00000020 80 90 e4 01 98 07 00 00 00 00 00 00 02 00 00 00 |................|
> 00000030 01 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000040 00 00 29 fb 1a 80 e5 73 61 6d 31 36 20 20 20 20 |..)....sam16 |
> 00000050 20 20 46 41 54 33 32 20 20 20 fa 33 c9 8e d1 bc | FAT32 .3....|
> 00000060 f8 7b 8e c1 bd 78 00 c5 76 00 1e 56 16 55 bf 22 |.{...x..v..V.U."|
right.
> but 'UDISK 2.0' occurs not long after:
>
> 00400000 55 44 49 53 4b 20 32 2e 30 20 20 28 00 00 00 00 |UDISK 2.0 (....|
> 00400010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00400020 e5 57 00 6d 00 63 00 00 00 ff ff 0f 00 b6 ff ff |.W.m.c..........|
> 00400030 ff ff ff ff ff ff ff ff ff ff 00 00 ff ff ff ff |................|
> 00400040 e5 2d 00 4e 00 6f 00 54 00 56 00 0f 00 b6 2e 00 |.-.N.o.T.V......|
the fact that one can observe it twice is because fat has a backup copy
of the table; however, what you have here is not the copy (since that
directly follows after the original, and not with such an immense huge
offset).
> I'm filing the bug against both packages because I don't know which one is
> doing the wrong thing. :)
there is more information needed, such as the whole partitioning layout
of the disk. also, if you're going to look at the things with a hex
editor, you need to make sure that you can rule out anything that does
not belong to the actual content (such as left overs from previous
operations that were not yet overritten by the filesystem).
either this is the case here that you have indeed observed a 'tainted'
fs, or, you hit some sort of delay of hal to get to know the changed
label. however, in both cases, this is not the fault of dosfstools,
since its operations are pretty much atomic here. therefore, reassigning
the bug to libvolume-id0.
Regards,
Daniel
--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: [EMAIL PROTECTED]
Internet: http://people.panthera-systems.net/~daniel-baumann/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
