Cloanto's Kickstart ROM 3.X and SFS

[psxphill]

From a purely technical perspective: SFS fills info->id_DiskState with the partition identifier (SFS\0) instead of the disk state (which should be DOS\0 for a validated disk),

According to the include file, it should be the number 82 for a validated disk.

struct InfoData {
   LONG     id_NumSoftErrors;   /* number of soft errors on disk */
   LONG     id_UnitNumber;   /* Which unit disk is (was) mounted on */
   LONG     id_DiskState;      /* See defines below */
   LONG     id_NumBlocks;      /* Number of blocks on disk */
   LONG     id_NumBlocksUsed;   /* Number of block in use */
   LONG     id_BytesPerBlock;
   LONG     id_DiskType;      /* Disk Type code */
   BPTR     id_VolumeNode;   /* BCPL pointer to volume node (see DosList) */
   LONG     id_InUse;      /* Flag, zero if not in use */
}; /* InfoData */

/* ID stands for InfoData */
   /* Disk states */
#define ID_WRITE_PROTECTED 80    /* Disk is write protected */
#define ID_VALIDATING      81    /* Disk is currently being validated */
#define ID_VALIDATED      82    /* Disk is consistent and writeable */

[psxphill]

Argh. id_DiskType, of course.

Well to me it looks like SFS should be putting SFS\0 in there and if something can't cope with that then that is to blame not SFS.

/* ID_INTER_* use international case comparison routines for hashing */
#define ID_NO_DISK_PRESENT   (-1)
#define ID_UNREADABLE_DISK   (0x42414400L)   /* 'BAD\0' */
#define ID_DOS_DISK      (0x444F5300L)   /* 'DOS\0' */
#define ID_FFS_DISK      (0x444F5301L)   /* 'DOS\1' */
#define ID_INTER_DOS_DISK   (0x444F5302L)   /* 'DOS\2' */
#define ID_INTER_FFS_DISK   (0x444F5303L)   /* 'DOS\3' */
#define ID_NOT_REALLY_DOS   (0x4E444F53L)   /* 'NDOS'  */
#define ID_KICKSTART_DISK   (0x4B49434BL)   /* 'KICK'  */
#define ID_MSDOS_DISK      (0x4d534400L)   /* 'MSD\0' */

[psxphill]

And this is the error most people make. No, this is NOT the partition type,  but rather DOS\0 to indicate a readable disk. Randy did that mistake in FFS, and then everybody believed to copy this mistake.Trick question: What does RAM: put there?

That is brilliant example of "look at all those soldiers marching, my son is the only one marching in time".

From the way the structure is named, RAM: should put RAM\0 in there. If what you're saying is true, then the person who wrote that structure was not very good at their job & whether it's readable should have been part of id_DiskState.

[psxphill]

Quick and dirty, no thought of supporting other filesystems than those shipping with it.

Well we know it was quick and dirty, for example the trackdisk.device used software decoding to find the sync mark until something like 2.0 even though all amigas could do it in hardware. I assume they wrote the code before the hardware was working and then never went back to fixing it.

Using the same identifier for the file system was a particularly poor choice and naming the variable so that the obvious interpretation was that it's a file system sealed the deal.

It reminds me of:

enum Bool
{
    True,
    False,
    FileNotFound
};

Trying to decode what the "correct" usage is therefore becomes a painful exercise. Especially when even official software supposedly went with the wrong interpretation.