Cloanto's Kickstart ROM 3.X and SFS

[Amigo1]

Hi,

has anyone with Cloanto's 3.X Kickstart ROM replacement for the A1200 noticed anything strange when using SmartFileSystem?

I had never used SFS on a 68k Amiga and did so for the first time after installing the 3.X ROMs.
All non-FFS partitions have an "additional" ghosted icon on the workbench. (for example "DH0:SFS\0")

This happens with all versions of the OS, from 3.1 to 3.9.

After watching countless tutorials I thought I was going crazy and fired up AmigaForever 7.

I could reproduce it very clearly. When using 3.X ROMs, the additional drive icons appear on WB.

Using the "Hidden Devices" option in "Workbench Prefs" does not help. There is only one entry for each partition, but strangely enough they are not consistent with the other ones: only the drive name is displayed (e.g. DH0) instead of the Partition name (Workbench3.1) as for the other FFS Partitions.

I checked with 3.1 ROMs and the latest BoingBag version (1.41) as I supposed some newer component was producing this, but apparently the issue occurs only when using 3.X ROMs.

So does anyone know a workaround?

[guest11527]

I had never used SFS on a 68k Amiga and did so for the first time after installing the 3.X ROMs.
All non-FFS partitions have an "additional" ghosted icon on the workbench. (for example "DH0:SFS\0")

This happens with all versions of the OS, from 3.1 to 3.9.

This is a bug in SFS, and one of the reasons why I am so skeptical about third party file systems. The best workaround: Don't use SFS. Is it still supported to get the bug fixed? No.

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), and hence workbench is confused. The matter is subtle, and it is easy to confuse one with the other, even more so since the same happened in the FFS which - again by a historical accident - uses DOS\n (n=0... instead of DOS\0 for the disk state. Other tools will be confused by this as well.

[Amigo1]

This is a bug in SFS, and one of the reasons why I am so skeptical about third party file systems. The best workaround: Don't use SFS. Is it still supported to get the bug fixed? No.

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), and hence workbench is confused. The matter is subtle, and it is easy to confuse one with the other, even more so since the same happened in the FFS which - again by a historical accident - uses DOS\n (n=0... instead of DOS\0 for the disk state. Other tools will be confused by this as well.

Wahoo, what a quick reply! Thanks!

Thanks for the technical explanation as well.

My aim was to speed up file operations and boot time on the cosy A1200 a bit.

Although your hint about third party FileSystems, I'll give PFS3 a shot and report here for completeness.

If it does have some quirks too, I'll revert back to FFS; but as I'm at it, to the latest version (should be 45.16 AFAIK).

FastFileSystem has served well for the last 2 decades anyway..

Amigo1

[matt3k]

I have used pfs2 and pfs3 since the 90's.  

They run stable and very fast.

The only thing to remember is that is you use a processor specific version that it may not be portable to another system.

Wahoo, what a quick reply! Thanks!

Thanks for the technical explanation as well.

My aim was to speed up file operations and boot time on the cosy A1200 a bit.

Although your hint about third party FileSystems, I'll give PFS3 a shot and report here for completeness.

If it does have some quirks too, I'll revert back to FFS; but as I'm at it, to the latest version (should be 45.16 AFAIK).

FastFileSystem has served well for the last 2 decades anyway..

Amigo1

[Romanujan]

Go to http://www.doobreynet.co.uk/amiga.html and try the SFS patch - it should fix the ghosted icon problem.

[Amigo1]

Thanks for the info! :-)

[kolla]

Are there alternatives to SFS if you need filesystem that works across all amiga derivatives as well as other OSes like Linux? Apart from FAT32 that is.

[guest11527]

Are there alternatives to SFS if you need filesystem that works across all amiga derivatives as well as other OSes like Linux? Apart from FAT32 that is.

FFS works on Linux, as long as you don't pick the Dircache variant.

If you think about it, this is so different from the situation on the Amiga, either...

[kolla]

FFS exists in so many variants that I have lost overview of which implementations are supported in which OSes, and what the consequences are if you mount one type of FFS as some other variant etc.

[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 */

[guest11527]

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

Argh. id_DiskType, of course.

[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' */

[guest11527]

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.

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?

[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.

[kolla]

If what you're saying is true, then the person who wrote that structure was not very good at their job.

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