#14 Filesystem incorrectly reported as DOS/0

Since SMBFS has various limitations, I want to be able to automatically work-around those, but at the moment it appears impossible to automatically identify when SMBFS is being used:
http://www.amigans.net/modules/xforum/viewtopic.php?post_id=102064#forumpost102064

The obvious way to identify SMBFS is using it's "DOSType" (also known as DiskType), but SMBFS unhelpfully reports this as 'DOS/0'. I'd argue this is a bug, since it's pretty much a lie.

My suggestion is that it report 'smbfs' or 'SMB/0' instead. Since uppercase letters are always used for real filingsystems, I think that lowercase letters could be used for virtual filingsystems like SMBFS or FTP Mount (but I don't know if lowercase letters are already reserve for some other purpose, as they are in AmigaE exceptions).

[Chris Young]

Line 2698 of main.c should read:
VolumeNode->dol_misc.dol_volume.dol_DiskType = 0x534D4200; // SMB\0

or whatever DOSType you think is appropriate (IIRC SMB does provide the host filesystem name, which is usually NTFS, ie. 0x4E544653)

[Olaf Barthel]

Sorry, this is a bigger problem :-(

What a file system reports as a disk type when asked through Info() or the mostly equivalent ACTION_DISK_INFO packet truly is the disk type and not primarily the file system type/signature (it must have started out as the file system type/signature, but then that practice became codified into using it as disk type instead). The disk type is provided primarily for the benefit of Workbench.

Workbench keys off this information to decide how to show the icon for the respective file system, and whether to show an icon at all. There are a handful of hard-coded disk types, which include whether there is no disk present (ID_NO_DISK_PRESENT), the file system has disabled access to the disk (ID_BUSY_DISK), the disk is unreadable/unformatted (ID_UNREADABLE_DISK), the disk is formatted but lacks sound file system structures (ID_NOT_REALLY_DOS) or if it's a Kickstart disk (ID_KICKSTART_DISK). If a file system wants to indicate that the volume is in good shape (readable/writable), it must report its disk type as something like "DOS\0". What's important is that the disk type starts with "DOS", the final character can be anything.

And that's the probleme here. Workbench and probably too much other software (which cannot be changed for practical reasons) needs file systems to "pretend" that they are "DOS?" even if their file system signature is something completely different, not to mention that the storage medium may not be a fixed disk either.

I cannot change the disk type returned by smbfs to anything but "DOS?" or you won't be able to use it with Workbench.

The problem with figuring out what the "true nature" of a file system really is keeps popping up again and again. There is no good solution for it yet which would cover all three AmigaOS family members (68k, OS4 and MorphOS).

[Chris Young]

Hmm, how do CrossDOS, SFS, CDs etc work at all, then?
In WB Information (RAWBInfo under OS4 which shows the DOSType), they are shown as SFS\0, MSD\0, CD\0\1 etc (and even mentioned in the OS includes!). As you say, there are a handful of special types, but anything else is treated as a valid disk.

[Olaf Barthel]

If I remember correctly, software can check the volume node disk type (in DeviceList->dl_DiskType, or DosList->dol_misc.dol_volume.dol_DiskType), which may be different from what Info() or ACTION_DISK_INFO will produce (these have to pretend that it's "DOS\0"). Mounting a file system on a fixed disk can end up storing the file system signature (first 4 bytes of the first sector) in the volume node (this is what the FFS and the default ROM file system will do).

However, because picking up the file system signature and storing it in the volume node is not mandatory, this is not a reliable key. For example, ram-handler will always store "DOS\0" there, so does CDFS. CrossDOS will put whatever is stored in its mountfile/mountlist entry.

[Anonymous]

@olaf
I'm not convinced by your last reply. For an OS4 SFS volume, I get 'SFS\0' from both:

1. FindDosEntry()->dol_misc.dol_volume.dol_DOSType
2. Info(lock, infodata) ; infodata->id_DiskType

So it is clearly acceptable to use something other than 'DOS\0'... as one might expect, given that dos/dos.h declares all sorts of "Disk types for; id_DiskType" (such as FAT, EXT, NTFS, NGFS, CD0, ...) .

If using any old "dol_DOSType" does NOT work, then there must be some internal OS database where valid disk types are registered... In which case it might be possible for SMBFS to register such a type too.

[Anonymous]

Also, Info(lock, infodata) ; infodata->id_DiskType gives the type "RAM\1" for the RAM: disk.

[Olaf Barthel]

AmigaOS4 sports a different file system architecture option (V53 and beyond, using a jump table), which has an API function for querying (among other things) the file system type, which can be more specific than the Info()/ACTION_DISK_INFO method. The workbench.library in AmigaOS4, however, still plays by the same rules as it ever did, namely invoking ACTION_DISK_INFO and keying off the id_DiskType value.

Because smbfs does not use the AmigaOS4 file system archtecture it cannot be queried using the method available to this type of file system.

I think the safest change to the smbfs that would allow you to identify smbfs as such would be through the change suggested by Chris Young.

[Anonymous]

@Olaf
"AmigaOS4 ... has an API function for querying (among other things) the file system type, which can be more specific than the Info()/ACTION_DISK_INFO method."

Are you talking about GetDiskFileSystemData()? I couldn't see how to get anything useful out of that, as far as my needs were concerned...

[Olaf Barthel]

There are two parts to this: GetDiskFileSystemData() will retrieve information about the file system, and the file system can play an active part in providing that information (through the FSFileSystemAttr() function or the equivalent ACTION_FILESYSTEM_ATTR packet). Without function/packet support GetDiskFileSystemData() will only provide information compiled from the various static device/volume/etc. data structures.

Few file systems implement the function or the packet yet. Those which do are typically using the new file system architecture (vector-port based filesystems).

smbfs has not been updated yet to even support the ACTION_FILESYSTEM_ATTR packet, which I will have to take care of eventually. In the mean time I'll change the value stored in the volume node DOSType field.