LABEL does not update the volume name in the BPB

[mateuszviste]

Label updates only the "volume file" in the root directory of the drive, but not the volume string in the BPB. I do not know why the volume name appears in two different places but surely the information should be the same in both places.

I suppose LABEL should call INT 0x21,AH=0x69 on top of creating the volume file.

It's easy to spot because SvarDOS TREE displays the BPB volume, while DIR shows the volume file.

Also checked on MS-DOS 5 - there LABEL updates the BPB correctly.

[boeckmann]

The label in the BPB is actually written directly by the kernel when a label file is created. At least this is the MS-DOS behaviour. This is a comment of mine over at the LABEL Gitlab repo. I cross post here in case an account es needed to read it:

So I checked that MS-DOS 6.22 and MS-DOS 4 LABEL indeed also set the BPB volume id. However, in the open sourced MS-DOS 4 LABEL version I found no trace of LABEL altering the boot sector. The volume id is set by the DOS kernel when a volume label file is created: https://github.com/microsoft/MS-DOS/blob/2d04cacc5322951f187bb17e017c12920ac8ebe2/v4.0/src/DOS/CREATE.ASM#L224

https://gitlab.com/FreeDOS/base/label/-/issues/1

[boeckmann]

I think that TREE should be updated to use the volume file insted of the BPB. But should be double checked how the MS TREE behaves.

[mateuszviste]

The label in the BPB is actually written directly by the kernel when a label file is created. At least this is the MS-DOS behaviour.

Are you saying this should be filled as an EDR bug? :)

I think that TREE should be updated to use the volume file insted of the BPB.

Possibly. It was the original pdTree behaviour btw. I changed it at some point because I used int 21h,ah=69h to read the BPB's serial number, and getting the label at the same time is essentially free.
But this opens an interesting question: which of the two locations is the canonical place that should be looked at, and why?

[boeckmann]

The canonical location is the volume file. Both the EDR and the FreeDOS kernel currently lack the ability to update the BPB volume id when the volume file is created. Indeed this should be created as an issue.

[mateuszviste]

There is a bunch of tools that display or set the volume name: vol, dir, tree, label, format, fdisk... maybe more (diskcopy?). it would probably be good to check them all and verify what they read/write. It's confusing to have this info in two different places, esp since the BPB one is more tolerant than the volume file (since it allows to use a name that is already taken by a file entry in the root directory)

[boeckmann]

We can remove FDISK from the list. It does not handle BPBs at all.

[boeckmann]

We can remove FDISK from the list. It does not handle BPBs at all.

Sorry, volume files... It has no knowledge of file systems.

[boeckmann]

Strategy should be: let tools use label file when possible, and let the kernel sync the BPB when label file is changes. FreeDOS FORMAT sets both, according to Eric Auer.

[boeckmann]

since it allows to use a name that is already taken by a file entry in the root directory

As far as I know, a label with the same name as an ordinary file can be created, at least under MS-DOS. But I will check a few things in the next days...

[boeckmann]

Corresponding kernel issue: SvarDOS/edrdos#118

[mateuszviste]

As far as I know, a label with the same name as an ordinary file can be created, at least under MS-DOS. But I will check a few things in the next days...

True. Tested and confirmed on MS-DOS 5, MS-DOS 6 and SvarDOS (EDR).

[boeckmann]

I did some tests with MS-DOS 6.22 and have to correct myself: even Microsoft FDISK shows the volume label, and not the BPB volume id for initialized FAT partitions. So the Microsoft tools indeed seem to make use only of the volume label apart from keeping the BPB field in sync.

I tested by using DEBUG to patch the bootsector with an altered volume ID:

- L 100 2 0 1
- E 12B 5A 5A 5A
- W 100 2 0 1

This sets the first three letters of the volume id to ZZZ. I then restarted and used the different tools to see if the volume label is used or the altered BPB volume id.

Confirmed to use the volume label:

• VOL
• LABEL
• FDISK
• TREE

[boeckmann]

Corresponding Free FDISK issue: FDOS/fdisk#88

[boeckmann]

Further tests revealed that the above listed tools ONLY use the volume label file, and do not revert to the BPB volume id if no file is found.

[mateuszviste]

So we know now that the EPBP volume string is only a nuisance. I wonder what was Microsoft's rationale behind introducing it in DOS 4. And who the int 21h,ah=69h call was destined for.

[mateuszviste]

TREE 20241011 uses a "findfirst" lookup for a VOLID file to display the volume label.
FDISK and KERNEL have separate issues reported.
I think this bug issue can be closed.