> > 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).
Thanks for the info. I think I have found the backup of the FAT and the
label is indeed correct:
00001000 eb 58 90 4d 53 57 49 4e 34 2e 31 00 02 80 d0 10 |.X.MSWIN4.1.....|
00001010 02 00 00 00 00 f8 00 00 3f 00 80 00 80 1f 00 00 |........?.......|
00001020 80 90 e4 01 98 07 00 00 00 00 00 00 02 00 00 00 |................|
00001030 01 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00001040 00 00 29 fb 1a 80 e5 73 61 6d 31 36 20 20 20 20 |..)....sam16 |
00001050 20 20 46 41 54 33 32 20 20 20 fa 33 c9 8e d1 bc | FAT32 .3....|
00001060 f8 7b 8e c1 bd 78 00 c5 76 00 1e 56 16 55 bf 22 |.{...x..v..V.U."|
> > 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).
Here's the layout of the disk:
# parted /dev/sdb print
Model: USB DISK 2.0 (scsi)
Disk /dev/sdb: 16.3GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 4129kB 16.3GB 16.3GB primary fat32 lba
I did the hex dumps while the filesystem was not being used for anything
else, on the assumption that if 'hd' read 'sam16' as the
label, /sbin/vol_id (or another libvolume-id-using program) would also
see the data.
Anyway I did the dumps after removing and re-inserting the device, and
even again later on a separate machine, so I think I can rule this
possibility out. :)
> 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.
Understood, thanks for your reply. :)
For the record, findfs from e2fsprogs also sees the label as being
'UDISK 2.0' and it does not link against libvolume-id--so this may not
only be a libvolume-id-specific bug.
--
Sam Morris <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
