Finding the real DosType of a volume

[BSzili]

I'd like to make a small program that prints out the real DosType for a volume/drive. For example "dostype dh0:" would print "FPS\3", "SFS\0" or "DOS\1" depending on the DosType value the user gave in HDToolBox.
From what I understand the the id_DiskType field in the InfoData struct is usually ID_DOS_DISK or ID_FFS_DISK for compatibility reasons. Some examples suggest the dol_DiskType field in the DosList struct reachable via id_VolumeNode, but that appears to hold a "DOS" compatibility-value as well. I'm wondering, is there a way to find the real DosType?

[jotd]

the first sector of the disk contains the fourcc of the real dos type.

[Toni Wilen]

Originally Posted by BSzili

I'd like to make a small program that prints out the real DosType for a volume/drive. For example "dostype dh0:" would print "FPS\3", "SFS\0" or "DOS\1" depending on the DosType value the user gave in HDToolBox.
From what I understand the the id_DiskType field in the InfoData struct is usually ID_DOS_DISK or ID_FFS_DISK for compatibility reasons. Some examples suggest the dol_DiskType field in the DosList struct reachable via id_VolumeNode, but that appears to hold a "DOS" compatibility-value as well. I'm wondering, is there a way to find the real DosType?

DosEnvec has it. (DosList->dol_Startup->fssm_Environ)

Originally Posted by jotd

the first sector of the disk contains the fourcc of the real dos type.

Yes but it gets problematic when partition start is outside of first 4G.

[Thomas Richter]

Originally Posted by BSzili

I'd like to make a small program that prints out the real DosType for a volume/drive.

As Toni said, the Environment contains it. If you look for a program that prints it, get "Devices" from Aminet. It prints all informations on a volume you could ask for.

[BSzili]

Thank you Toni and Thomas, this is what I was looking for! Can this be extended to locks of arbitrary paths? Finding the actual volume that holds "Work:SomeDrawer" for example, and then printing the DosType of that volume?
I tried finding an entry in the LDF_DEVICES list with a matching dol_Task to the lock's fl_Task, and I found the device name and unit number (e.g. uaehf.device unit 1), is this what I'm looking for? I found the volume's DosList too via the same method, just checking the LDF_VOLUMES list, but the dol_Startup for that entry was 0.
edit: I also tried checking the lock's fl_Volume DosList, but that one also has a 0 dol_Startup.

[Thomas Richter]

Yes. Look for the handler in the dos list whose dol_Task points to the same message port as the fl_Task in the file lock structure. From there, navigate to dol_Startup, which may be a number, or a BPTR to FileSysStartupMsg (see dos/filehandler.h). There is a BPTR to the environment, and this contains the dos type.

[BSzili]

This worked great, I tried on a couple of volumes with different file systems, also verified with the Devices program. You mentioned that dol_Startup may be a number. Should I check if it's a valid FileSysStartupMsg BPTR? For example if TypeOfMem(BADDR(dol_Startup)) is non-zero, then it should be the fssm pointer?

[thomas]

Originally Posted by BSzili

Should I check if it's a valid FileSysStartupMsg BPTR? For example if TypeOfMem(BADDR(dol_Startup)) is non-zero, then it should be the fssm pointer?

Yes, and also check that it is higher than 1000 or so, because TypeOfMem(small number) will return MEMF_CHIP, but is not a valid FSSM.

[Thomas Richter]

The problem with dol_startup is that it is actually private to the file system what exactly it means. In principle, it could also be a C pointer or a pointer to something completely different than the documented startup message. Thus, it is not really completely safe to interpret it as a BPTR, even though in relality I haven't seen a handler on the Amiga that does not use it as either as a number or a BPTR to the startup message.

[BSzili]

I suspected this would be the case, but for now it's good enough that it works with the most common file systems (I tried it with FFS, PFS, FAT32, emulated WinUAE directory drives, etc.). If I encounter one that doesn't play by these rules I can always add workarounds later.