What is the max length of the extra "fname" return parameter ?
it seems to be less than 80 chars, is it ?

Good detective work. There is an 80 character temporary variable (re-used from some other original purpose) which is used to format the combination of the flags[/i[ and [i]file (i.e. parameter #7, which I believe you are referring to as fname) parameters of MX_GETOFD .

I guess I figured that 70 characters or so was more than enough to hold a typical file.ext (since after all, in the AMOS world, we were dealing with a 6.3 limitation). But in the "real world", I suppose we should allow for considerably more, although we start dealing with absurdly large filenames, it's hard to know where to stop. If, say, a 90 character long name is reasonable, what about a 900 character long name?

I should mention that A-Shell is mostly using 260 as the maximum length of a fully-qualified path (directory + filename). (This is more or less the Windows API standard, although technically some filesystems, like NTFS, can handle filenames of nearly unlimited length.) Usually if a path name is in danger of exceeding 260 characters, it would be due to a deeply nested directory rather than a long filename. But perhaps I'm stuck in a 20th century mindset.

I'll be happy to increase the size of this particular buffer from 80 to ... 260(?) in 1222.3, although if you want to comment first, please go ahead.

Sorry to come back late, 260 is perfect. Indeed various problems occur when full pathnames exceed 256 char long, with some remote FTP backup software by example.
About 21th century, I just can just say that sometimes I sigh with nostalgia, thinking back to my first Apple ///, AM1200 and other Canon XO7.

Ok, I'll expand that particular buffer to 260 in 1222.3, due out sometime in the next 24-48 hours.

(In the meantime, you can go back to playing with your AM1200.) :p