Inconsistent host dependent behavior for UNPACKFILENAME.STRING

[rmkaplan]

I am trying to understand what’s going on in UNPACKFILENAME.STRING (actually rewriting to bring it under control) to fix some of the odd behavior we have noticed (name-fields beginning with dots, extensions with all digits…).

It has a call (SETQ OSTYPE (GETHOSTINFO HOST 'OSTYPE)) and it appears to use that decide what version indicator to allow ; usually but also ! for IFS, . for TOPS20.

If HOST is DSK, it returns IFS. That seems like a bug. For UNIX it returns NIL.

But then the use of period in the TOPS20 case may not be confined to just the TOPS20 host (the code is really complicated), but that might be source of the counter-intuitive behavior that Nick encountered:
123 is a version for {DSK}a.b.123

• is a version for {DSK}a.b.*
  x is an extension for {DSK}a.b.x
  but
  123 * x is an extension if there is only one dot (e.g. {DSK}a.123)

So the last dot is not consistently an extension, it depends on the actual characters that follow, whether or not the host is tops20.

The is could be fixed for all practical purposes by making the last period of a sequence of periods a version indicator more specifically only for TOPS20 (which we presumably will never see). For TOPS20 there would still be inconsistent behavior.

Or, the period case can be deprecated entirely. And maybe the exclamation case also. When inside Medley, filenames should be specified in "Medley standard format" strings. The existing device-specific functions for recognition and generation should always coerce to and from Medley-standard syntax.

The commonlisp path abstraction is an attempt at a syntax-independent solution, but insisting on that everywhere would tilt the whole system. But the unambiguous parsed format (equivalent to a path) can be created from a Medley-standard string (by UNPACKFILENAME.STRING) going into a device, and PACKFILENAME can create a Medley-standard string on the way back. The device would traffic only in preparsed fields, and above the device level there would only be Medley-standard strings unambiguously related to commonlisp paths.

The current set up is complicated and inconsistent.

[nbriggs]

When I do (GETHOSTINFO 'UNIX 'OSTYPE) it returns IFS, which is what DEFAULT.OSTYPE is set to.

[rmkaplan]

Oh, maybe I mistyped. I see IFS now too. But not much better.

…

On Mar 30, 2022, at 10:51 AM, Nick Briggs ***@***.***> wrote: When I do (GETHOSTINFO 'UNIX 'OSTYPE) it returns IFS, which is what DEFAULT.OSTYPE is set to. — Reply to this email directly, view it on GitHub <#757 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJMDQPV2OZDEXS4II6DVCSIDPANCNFSM5SCV5WHA>. You are receiving this because you authored the thread.

[nbriggs]

I think IFS for DSK is correct, since the Maiko code is simulating the IFS and Alto local file system behavior for the DSK device. I believe the IFS native version separator was "!", probably from the Alto file system also using "!", but I don't know anything about the history of ";".

[nbriggs]

TOPS20 filename syntax is

dev:<dir>name.typ.gen;att;att;...;att

typ is the file type, gen is the generation number (version), att is a file attribute, not usually used. There were no subdirectories.

[rmkaplan]

; was from Tenex/Maxc We can continue to parse both ; and !, those are both unambiguous. But we should pick only one when we pack up—currently it’s ;—as the standard. ! on the parsing side is just a bit of convenience, but is there a reason for any other device dependence at this level? BTW, is there any specification anywhere of the other undocumented arguments: DIRFLG and CLFLG? CLFLG seems only to be used to say whether the colon should be kept on the device. DIRFLG seems to have values like RETURN and FIELD. Note also: CLTL2 specifies a function CL:PARSE-NAMESTRING (on CMLPATHNAME) that looks a lot like UNPACKFILENAME.STRING in terms of (the complexity of) its internal logic. Apart from interface issues (defaults etc.) are those supposed to have a core of common behavior? Could the CL function be a wrapper around the Interlisp function?

…

On Mar 30, 2022, at 11:35 AM, Nick Briggs ***@***.***> wrote: I think IFS for DSK is correct, since the Maiko code is simulating the IFS and Alto local file system behavior for the DSK device. I believe the IFS native version separator was "!", probably from the Alto file system also using "!", but I don't know anything about the history of ";". — Reply to this email directly, view it on GitHub <#757 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJMNG4RA37V2AKOM6HLVCSNGXANCNFSM5SCV5WHA>. You are receiving this because you authored the thread.

[rmkaplan]

One other oddity: If you give UNPACKFILENAME.STRING or the CL function a path, it unpacks the path into its components. But unlike what you get by unpacking a string, the directory field contains its leading and trailing brackets.

[nbriggs]

The Maiko code only accepts (and generates) the ; form, which it converts back and forth between name.extension.~version~ for the underlying storage name. I don't know about the other undocumented FLGs. I'm not sure at exactly what level in the device dependent/independent hierarchy of names UNPACKFILENAME.STRING is likely to get invoked...

[nbriggs]

Back on the OSTYPE -- outside of DSK and UNIX as special hostnames, it should know about NS hosts (from the colon in {eg:}), NFS hosts (using the Lisp NFS implementation, from the /n in {tigger/n}), and IFS. I don't remember the underlying form for XNS file names, I think I only saw XNS hosted files through the regular Interlisp syntax.

[masinter]

There's an IFS implementation that's part of the livingc omputer museum contralto.
There are files with .N versions in the History repo from the 70's and 80s.

I like the idea of using libcurl and having a "curl" file system, where the file names are URLs.