Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Amigo1 on February 11, 2018, 09:36:57 AM
-
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?
-
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...8) instead of DOS\0 for the disk state. Other tools will be confused by this as well.
-
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...8) 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
-
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
-
Go to http://www.doobreynet.co.uk/amiga.html and try the SFS patch - it should fix the ghosted icon problem.
-
Thanks for the info! :-)
-
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.
-
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...
-
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.
-
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 */
-
According to the include file, it should be the number 82 for a validated disk.
Argh. id_DiskType, of course.
-
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' */
-
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?
-
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.
-
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.
-
Silly question - why does this bug manifest itself only in exec v45 and up?
-
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.
-
Silly question - why does this bug manifest itself only in exec v45 and up?
It does not. SFS has a version check in it, that is why. Exec is completely unrelated.
-
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.
As far as the trackdisk.device is concerned: At the time trackdisk was written, PAULA was not yet completely engineered. In fact, it was called PORTIA back then, and PORTIA did not have automatic synchronization to a sync word. This was added "last minute". You find this in the ancient trackdisk sources. There was apparently no time to "clean up" trackdisk, and since it worked, nobody cared - there was more important stuff to do.
As far as Info() is concerned: Tripos was an academic exercise, and many details where engineered in an "ad hoc" way, without giving too much thought on the details and the implications. Look for example at ACTON_EXNEXT. This packet is almost impossible to implement correctly, and the way how OFS handled it, was outright naive and could have only worked in non-multitasking environemtns.
Trying to decode what the "correct" usage is therefore becomes a painful exercise. Especially when even official software supposedly went with the wrong interpretation.
That was not the only mistake that was introduced with FFS: OFS has a pretty useful interpretation of the read/write open mode that locked the file from other processes similar to ACTION_FINDOUTPUT, but unlike the latter, did not overwrite it. This was messed up by FFS which only requests a read-lock on READWRITE, and thus allows two tasks modifying the same file at the same time. Unfortunately, this bug was then back-ported to the Ram-Handler as well. Oh well...
You find such hisitorical errors all over the place. This is just one of them.
In case you care: You find the partition type in the mount list aka the Environment-Vector.