The Sinclair QL Forum

This topic keeps coming up once a year, I feel. (And buried again shortly after...)

The maximum length of a file name in QDOS is deeply interwoven with the file header structure (because it needs to fit in there, not only on the actual media, but also when the name/header is handed around in the OS. In hindsight, it probably wasn't a very good idea how the support for sub-directories was "hacked" into the existing system).

It's also imprinted in the channel definition block (because that needs to hold the full path name as well).

There's no easy way to work around these fixed-size structures without re-writing major parts of the I/O subsystem. Even worse, even if you did that, there's also no easy way to stay compatible with traditional QDOS file systems.

Proposal: Stop whining and live with it

Well, the main thing is that you said something again. how about something constructive?

Tofros famous words:

Proposal: Stop whining and live with it

Leave me alone, don't comment on anything from me and take care of other things. I think you understood me now!

Didn't like that I didn't like your Magnetic Scrolls interpreter? But that's your problem, not mine.

Gentlemen, please. We can agree to disagree.

Tofro: we know the problems, and we know the solution(s), if any, will be difficult and will lead to compatabilty problems, but we can but wish!

I agrrevwith your hypothesis that hacking actual directories is the real problem, until then, 36 characters seemed ok, but if younare used to the directory structure on othr systems, you feel thatbyounare missing out with the level 2 drivers.

Cheers,
Norm.

Hi,

How about making each directory have 36 characters, which under the current filesystem looks to be not possible.

But, using the SUB, NFA device drivers in QPC2 and SMSQmulator, can have 36 characters in each defined native file system direvtory.

it makes you wonder if an inode type system could overlay the present file system, which would continue to work as it has always done. If you specify a longer name - an inode is created and stored in the current file system, along with another file that maps the inode to it's longer filename. At any point where the user interfaces with the file system, he would only see the existing 'normal' files, or the longer name which uses the inode file format at the lower level, but presents a nice human readable to the user.

Good lord, Ralf, chill. I'm with Tobias on this one. The problem is not the device drivers. The problem is that there is no application facing API that supports longer names! And what use are longer names if you cannot even do a DIR on them? The whole concept is so interwoven into every piece of QL software out there that it's just hopeless to fix.

Getting back on topic, I actually watched my own talk just now and unlike my expectations I must say I'm pretty happy with it, especially considering that I was mostly talking off-the-cuff. Oh, except the constant mix ups of eighty-six and sixty-eight, that was painful to hear in retrospect Anyway, I'm not used to talking English, just writing it (revising every word 4 times), so I'm happy that it was halve-way coherent and fluent.

The Q&A session was at least another halve hour or so and somewhat interesting, but as they say, you had to be there

Cheers

How about super imposing a parallel system that works a bit like QPC's DOS device? Mount old devices somewhere on the directory tree. eg MOUNT 'WIN1', '\somewhere\win1'. Anything under 'win1' has to conform to the old conventions, and can be accessed in standard ways, with a bit if OS trickery, if necessary. New programs, like file managers and the like, would use system-provided calls to read the super directory structure. Old programs would only see old-style devices.
This is more or less how my simple DOX file browser works on the DOS/NFA devices. I guess a lot of the directory conversion magic happens at high speed on the PC side, but then such a driver would mainly be aimed at high-end QL systems, which may have enough omph to cope with it natively without appearing sluggish.

What could indeed be done relatively easily is give each drive a variable prefix that could be set to be able to extend pathnames beyond their current limit - That would end up in something like the sub_ device mixed into the file system driver, allowing the system to dig deeper into a file system tree.

Obviously, that couldn't work with existing on-disk native QDOS file systems, and it would still be a kludge and not a real solution to the problem.

With a bit of clever thinking, I think it's way easier (and less error-prone) to work within the existing limits. I tend to have really big file systems and have actually not encountered a situation yet where I couldn't find a work-around with a bit of re-naming and moving stuff around.

mk79 wrote:Getting back on topic, I actually watched my own talk just now and unlike my expectations I must say I'm pretty happy with it, especially considering that I was mostly talking off-the-cuff ...

Marcel, congratulations!!, a nice presentation. Very interesting, I liked it a lot.