11-character filenames?

[hjalfi]

(Warning: rubber ducking follows.)

So, a while back I did a port of CP/M to the 6502. One of the supported systems is the BBC Micro. It works pretty well, at least if you have a Tube machine (it will run on an unmodified Model B provided you're in MODE 7 and don't really want to run any programs). See: https://github.com/davidgiven/cpm65 (It has a Pascal compiler now!)

Recently I did a port to the Olimex neo6502. This is interesting, because this has a coprocessor which implements a FAT filesystem and provides file-level access to the 6502 CPU. So instead of just putting the CP/M filesystem in a big file, the way it works on the BBC Micro, I instead did BDOS emulation so that it uses the underlying native file system. This is vastly more convenient.

I'd rather like to do something similar for the BBC Micro port. After all, on a Tube system or a BBC Master you get the filesystem for free. Using it would be much more useful. Unfortunately CP/M filenames are the classic 8.3 format and won't fit in a 10-character ADFS filename... (and I don't think DFS is at all worth considering here).

So how can I fit a 12 (or 11, if you don't include the dot) filename onto a BBC Micro filesystem?

- use a filesystem which supports longer filenames. Are there any? I'm not aware of any.
- use a filename map file. This is ugly, slow, fragile and inconvenient.
- use multiple filename entries, VFAT-like. This could probably be made to work but is really complicated. That "FNORD.COM" would end up as two file entries,"FNORD/~Lxx" and "COM____~Rxx" where xx was a random unique ID and the L and R indicate different halves of the filename. The actual data would be in one half and the other would be a zero-length file.
- use subdirectories.

The last seems like the only viable option. So, the CP/M file "FNORD.COM" goes in "$.COM.FNORD". Except, it's kinda slow as (IIRC) ADFS caches the current directory only, which would be $ here, and so I'd get an extra seek every time I opened a file. Any native ADFS files with filenames longer than eight characters couldn't be mapped to CP/M filenames, but I can live with that, though. One concern is that It makes iterating directories really annoying as I'd need to iterate across multiple ADFS directories.

(In case it's not obvious, I can't put the file extension in the ADFS file metadata fields, like RISC OS did, because "FNORD.ASM" and "FNORD.COM" would both end up in the same "FNORD" ADFS file.)

Have I missed anything obvious?

[BigEd]

I think Panos uses the directory method.

I wonder… could you just drop one letter off the extension? Perhaps the middle letter. Perhaps have a lookup table for all common extensions and their abbreviations??

[SKS1]

(In case it's not obvious, I can't put the file extension in the ADFS file metadata fields, like RISC OS did, because "FNORD.ASM" and "FNORD.COM" would both end up in the same "FNORD" ADFS file.)

Filenames still have to be unique on RISC OS. You can only have one FNORD in a directory.

[SKS1]

I think Panos uses the directory method.

Indeed - it mapped leafname-ext to _ext.leafname, where _ext was a directory.

And on RISC OS, there was no OS mangling for filename extensions (till DOSFS), so tools like the Norcroft compiler and friends used to map leafname.ext to ext.leafname, where ext was a directory.

I wouldn't worry about performace of an additional seek to the ext dir on BBC Micro ADFS, surely having it working at all is better than nowt?

[BeebMaster]

And surely, though I would be delighted if all this was being done using floppy discs, it is being done with flash memory ADFS hard disc storage? Meaning the additional read time to traverse down a directory is going to be infinitesimal.

Even if using floppy discs, if the disc is organised so that the filename-extension-directory object is next to the actual-file-storage-directory object, then it is only 5 sectors away, which will at most need a single track step if the two neighbouring directory objects do traverse a track, and could probably be avoided altogether with some judicious disc layout in advance.

When I was having a go at writing my own file server a couple of years ago, I started to devise a spec whereby all the directory entries were dummy filenames, maybe as simple as 01 to 46, but they were the actual files, and the 47th entry was a lookup table between the dummy filenames and the actual filenames, so potentially the filename length could be unlimited, although I decided on 16 characters at the time. This also allowed more information to be held in the lookup file than could be held in the ADFS directory structure, eg. date stamps etc.

In addition, to implement the Econet spec of up to 255 (or 254) files per directory, certain directory entries out of the remaining 46 available were themselves directories into which the overflow files were stored.

[paulb]

So how can I fit a 12 (or 11, if you don't include the dot) filename onto a BBC Micro filesystem?

- use a filesystem which supports longer filenames. Are there any? I'm not aware of any.

The Kenda Disc Management Filing System supported eight-plus-three filenames:

Where possible, the DMFS commands follow the conventions used in CP/M so making it very familiar to someone who has used CP/M before. The file specification, for example, has both a filename and an optional file extension. The filename can be up to eight characters long and is followed by a file extension of up to three characters.

"Just the Business", Acorn User, July 1986.

[hjalfi]

The Kenda Disc Management Filing System supported eight-plus-three filenames:

Hilariously, it seems to do this because it is the CP/M file system! https://www.4corn.co.uk/archive/showpdf ... 20PADS.pdf (Which makes sense. The CP/M file system is unironically a really good non-hierarchical file system. I'm kinda surprised that Acorn rolled their own for DFS.)

Even if using floppy discs, if the disc is organised so that the filename-extension-directory object is next to the actual-file-storage-directory object, then it is only 5 sectors away, which will at most need a single track step if the two neighbouring directory objects do traverse a track, and could probably be avoided altogether with some judicious disc layout in advance.

Hmm. Potentially. Creating directories in advance would be as easy as just doing a bunch of *CDIR calls before creating files. And provided that the subdirectories were between the root directory and the file itself, the performance hit wouldn't be bad. Also, it occurs to me that the 47-file limit per directory on ADFS means that splitting files up between subdirectories is a good idea anyway. Okay, sold!

[tom_seddon]

Regarding existing filing systems that support longer names: BeebLink does support 11 char names (just): 1-char DFS-style "directory" plus 10-char name.

sweh's TubeHost HostFS server (https://github.com/sweharris/TubeHost) supports 255-char names. BeebLink also has a TubeHost interop mode (so you can use your TubeHost files), and the same 255 char limit applies there as well.

(I do intend to make BeebLink support longer names more widely, but it's not been a high priority.)

--Tom

[tricky]

I don't suppose you could store the extra character in the top bits of the first 7 characters could you?
This wouldn't get over the number of files limit.

[jgharston]

ZNOS for the BBC, which gives network access for CP/M on the Z80 CoPro, uses the EXT.FILENAME method. For example, CPM filename "CCP.SYS" is host filename "SYS.CCP", CPM filename "LONGNAME.TXT" is host filename "TXT.LONGNAME".
See https://mdfs.net/Software/CPM/ZNOS/