Detecting a >77 files/directory filesystem

I have a need to verify that something is running on a filesystem that supports >77 files in a directory (because it’s about to dump ~143 files).

I figure that I could canonicalise the path to get a filesystem prefix (like SDFS and :0), and then call SDFS_DescribeDisc on it to read the media descriptor.

Looking at StrongHelp, it seems that:

• Words &28-&2F clear, it’s a “Small” disc (<= 512MB?)
• Byte &29 non-zero (bit 0 will be set), its a “Large” disc (> 512MB)
• Word &2A non-zero, it is a “Big Map” disc. (?)
• Word &2C non-zero (ought to be 1), it’s a “Big Dir” disc). (long filenames?)

At which point was >77 files introduced? I suspect I might want to just check if &2C is or is not non-zero (just assuming “Big Dir” means >77, and not just long filenames). Is this correct?

Of course – it doesn’t help that the documentation doesn’t mention this at all…

Edit: Correction, the site is buggy and only claims there are 143 pages. If you carry on going… there are actually 408 pages!

At which point was >77 files introduced?

When I looked into this in the autumn, I found that it was introduced in FileCore 3.21. It was tricky to work out what OS version this meant, but I decided on 4.03, I don’t even know if that’s a real public release or not! In any case the “FileCore functional specification” documents are dated 1997/98 to give you an idea.

I suspect I might want to just check if &2C is or is not non-zero (just assuming “Big Dir” means >77, and not just long filenames). Is this correct?

Big directiories means > 77 and long filenames both, and you’re right that you look at byte 44, see “FileCore phase 2 functional specification” 3,14,5.

Of course – it doesn’t help that the documentation doesn’t mention this at all…

Yes it would be good to update it with big directories stuff.

At which point was >77 files introduced?
When I looked into this in the autumn, I found that it was introduced in FileCore 3.21. It was tricky to work out what OS version this meant, but I decided on 4.03, I don’t even know if that’s a real public release or not!

RISC OS 4.02 had >77files/directory. RISC OS 4.03 was released with the Kinetic processor, I think.

Think about a Sunfish mount (an image file) on an old-filecore disc. You will have 77 entries/dir surrounding it, but whatever-limit-NFS-has/dir inside it.

Think about ShareFS. How do you know what the other machine supports?

There is IMHO no way to pre-detect any limit. Keep in mind that new filecore formats also have limits (depends on many things, but sometimes as low as 80000 entries/dir IIRC). You have no other choice to fill up the directory and handle any error that occurs.

RISC OS 4.02 had >77files/directory. RISC OS 4.03 was released with the Kinetic processor, I think.

correct, AFAIR long file names and unlimited files per directory arrived with RISC OS 4.02.

RISC OS 4.02 was built from Acorn RISC OS 3.80 which should be the one never released.

Think about ShareFS. How do you know what the other machine supports?

Not relevant – there’s no ShareFS_DescribeDisc SWI, so the only option is to plough on until it starts failing.

I don’t have Sunfish, but I’d imagine it would be the same (image FS rather than FileCore FS).

There is IMHO no way to pre-detect any limit.

I’m not looking for detecting a high limit, more for detecting “more than 77”. And, obviously, I can only provide a “can’t do this” if I positively identify a filesystem that cannot.

You have no other choice to fill up the directory and handle any error that occurs.

Thankfully, I have found a better method than dumping ~400 files into a directory. ;-) The only choice as it was before is to try to identify those systems that would definitely fail and simply not bother. As for all the rest, well, as you say there’s no clear way to tell what the limits are so the only method would be suck-it-and-see.

built from Acorn RISC OS 3.80 which should be the one never released.

Back in the day, there were some development modules floating around that would give long filenames (and, I guess, >77 files/dir) to RISC OS 3.70 machines. I did have them once ¹ but I never used them as the ReadMe had multiple warnings that it was not even to be considered a beta test version of FileCore and it may well trash the filesystem and as it was a format unknown to fsck, recovery was basically you and a sector editor fixing a format that wasn’t publicly documented…or restore from backups.
I heeded the warnings. ;-)

¹ No idea if the media still works.

I don’t have Sunfish, but I’d imagine it would be the same (image FS rather than FileCore FS).

Sunfish is the same as any Image FS, i.e a file can be used as a directory. Therefore, it can be placed on an old FileCore format FS and allow for paths inside it with more than 77 files/dir. ImageNFS, LanMan98, TBAFS, X-Files, SparkFS, Win95FS…every workaround (apart from raFS) the seasoned RISC OS 3.x user ever used to work around the dreaded FileCore limits would not work with your “solution”.

But I am not sure what exactly your use case is. If you are using an existing path to dump the files, you cannot control how many files/dirs the user already placed inside. If you are using your own freshly created path, you can use the old NewsBase “dir in a dir in a dir” method to allow for nearly unlimited files.

When I looked into this in the autumn, I found that it was introduced in FileCore 3.21. It was tricky to work out what OS version this meant, but I decided on 4.03, I don’t even know if that’s a real public release or not!

New Filecore “big dir” format was introduced in RISC OS 3.8. There were developer versions floating around that were softloadble on RISC OS 3.7. I had an early access RISC OS 4.00 version (Flash ROM on carrier board), and it certainly already supported the new format. RISC OS 4.02 was the “general access” bugfixed version of 4.00 that was actually burnt into proper ROMs. RISC OS 4.03 was the version for the various 3rd party machines like RiscStation and Mico.

Anyway, it is important to stress that “>77 entries/dir” is a feature in all versions of RISC OS at least going back to 3.00, because the limitation was always FileCore and never FileSwitch. So e.g. on RISC OS 3.10 you could have any FS with unlimited entries/dir like LanManFS, NFS, raFS, Memphis-with-slave-file, DOSFS, CDFS…

Back in the day, there were some development modules floating around that would give long filenames (and, I guess, >77 files/dir) to RISC OS 3.70 machines.

Yup as well as the alternative FSes that allowed “>77 entries/dir” from RISC OS 3.xx, so do you want to support every “permutation” (included developers only/beta code)?

Anyway, it is important to stress that “>77 entries/dir” is a feature in all versions of RISC OS at least going back to 3.00, because the limitation was always FileCore and never FileSwitch

Correct, and I’m looking to update FileCore in RISCOS 3.20 to resolve the issue on original Arc’s, so you can go by OS version.

>77 entries per directory has always been possible, possibly since RISC OS 2 times. It’s never been an OS limitation (nor has 10 character filenames). ADFS ‘L’ format was limited to 47 entries too, so it wasn’t even always 77.

Just because Filecore didn’t support it didn’t mean other FSes didn’t. I am pretty sure SJ Research fileservers could have more, and they date back to the beeb.