• Please review our updated Terms and Rules here

Thought experiment: CP/M directories

There's only one other thing I can think of - Firefox has this https-only mode which should be turned off. I haven't tried it, so I don't know what effect it would have on http sites, but it might be worth looking at.

Tools, Settings, Privacy & Security, scroll all the way to the end. Choose "Don’t enable HTTPS-Only Mode".

The reason I recommended Google DNS (or anything outside of your ISP) is that I was getting random 403 and 404 errors, on various sites. Switching over fixed all that.
 
Very belatedly: I've been thinking about this again...

Parsing a path would involve doing multiple directory scans, once for each path element, looking up the directory ID for each element. That's going to be pretty slow but I think it's unavoidable.

Rendering a path would also involve doing multiple directory scans. Each file's UU byte would contain the ID of its enclosing directory so to get the name we have to find the dirent. Except, we need to do this in reverse. Storing multiple FCBs is kinda beyond the capabilities of something like the BDOS. We could store the directory IDs, as they're a byte each, but that would double the number of lookups required. I suppose we could render the string backwards and then reverse it as a final step... so using the output string buffer itself as storage.

A file will store its enclosing directory ID in the UU byte. I was originally thinking that this would be the dirent index of the directory. An alternative is to allocate arbitrary IDs and place them elsewhere in the dirent. I was originally thinking of S1 but that actually makes life complicated as various tools will set S1 for exact-byte file lengths. However, since a directory entry will contain no storage, RC is usable instead. I think I really prefer the dirent index approach, but the directory entries will need to be spread throughout the directory to avoid being unable to create new directories on a disk with more than 250-ish dirents. That will also make path rendering faster, as we can seek directly to the appropriate directory sector.

If a non-directory-aware OS fiddles with a directory it'll stop working but I can't help that.

If someone deletes a directory entry, all files within the directory will become inaccessible. So I'll need a fsck equivalent to find them again.

Extra BDOS calls will need to be: mkdir, getcwd, chdir, parsepath and renderpath. Delete and rename will act as before. Open will need to be modified to refuse to open directory entries.

The biggest cost are the new parsepath and renderpath system calls, as they're likely to be big...
 
Just realised: FCBs put the drive number in the first byte, where dirents put the user number. So in order to have FCBs which point at a file in a specific directory, I would need to put that information elsewhere. I could either increase the size of the FCB, or repurpose one of the other bytes. Looks like S1 is going to get it after all...
 
Back
Top