File systems and file service on CADR and Genera

From a PDP-10 name to a host-independent object

System 46's file manual describes a machine whose ordinary files live on an AI Laboratory PDP-10. Its QFILE implementation nevertheless already separates a host description, host-specific filename syntax, file channels, and Lisp streams. The later generic pathname model makes the separation explicit. A pathname has six conventional components—host, device, directory, name, type, and version—but each host supplies its own parser and printer. Parsing a pathname does not prove that the file exists; opening or probing it resolves the name and can return a truename.

System 303's FILE-SYSTEM declaration makes this structure visible in its load order: basic access and pathname code, host pathname syntaxes (including logical, LMFILE, and older local-disk syntax), file I/O, then Chaos QFILE. The pathname layer is therefore not an alias for QFILE. The same pathname and stream clients can be backed by a local store or a remote server.

Genera preserves that model and makes access selection a first-class object. An active pathname asks its host for a file access path for the requested operation. If the host has no cached access path, it invokes the network FILE service; the selected network protocol constructs the appropriate access-path flavor. A pathname's host syntax and its transport are consequently related but distinct. The access path also remembers its open streams and login state.

Complete Genera active-pathname operation inventory

The following 15 operations are every direct delegation in the inspected active-pathname-mixin:

PATHNAME-FILE-ACCESS-PATH is a source-visible efficiency side door used by OPEN; it avoids repeating higher-level message dispatch but does not change the selection semantics.

OPEN at the Genera 8.5 source boundary

The generic wrapper's complete directly recognized controls are:

The wrapper merges defaults, forces a logged-in user context, canonicalizes obsolete forms, computes Common Lisp defaults, and then calls FILE-ACCESS-PATH-OPEN with the translated physical pathname as well as the user-facing pathname. This explains why the same Zmacs or Command Processor operation can preserve a logical/user name while the stream reports a different truename.

What existed at this boundary

The System 46 manual does not describe a self-hosting CADR file system. It says that the machine uses the AI PDP-10 file system and presents local Lisp-machine file systems as future work. The implementation loads QFILE and registers remote file computers such as ITS and TOPS-20 hosts. The server in this snapshot is not Lisp code running on the CADR: lmio/file.238 is the MIDAS source for the PDP-10 FILE job.

The later names LOCAL-FILE, LFS, and LMFILE must therefore not be projected back onto System 46 merely because a later CADR load band contains them.

How QFILE works

QFILE opens a Chaos control connection to contact name FILE. Commands and replies carry transaction identifiers, so control transactions can be outstanding while data moves. Separate reusable bidirectional data connections carry file bytes. Each half of a data connection can serve one input or output file handle, and closing a file does not inherently close that data connection.

The client tracks file-channel direction, character/binary mode, control and data connections, open/closed/EOF state, and synchronous or asynchronous mark state. Synchronous marks delimit changes such as file position or byte size. An asynchronous error suspends a channel until it can be continued or abandoned. The who-line shows active file operations and progress.

The client caps an ITS host unit at three reusable data connections and a TOPS-20 unit at eight. The source also warns that two independent users of one channel are not serialized safely. This is a concrete implementation limit, not a general property of later file protocols.

An older file in the same snapshot, lmio1/qfile.173, is a different interim implementation built around shared wired QIO buffers and a communication area. It allows only one input file and one output file at once. Its presence records lineage; it is not evidence that the later lmio/qfile.31 has that same two-file limit.

Complete System 46 FILE server command table

The PDP-10 dispatcher compares only the first five characters of command names. Its ten common commands, plus one ITS-conditional extension, are:

The complete OPEN option table is READ, WRITE, PROBE, CHARACTER, BINARY, BYTE-SIZE, RAW, and SUPER-IMAGE, with TOPS-20-only TEMPORARY and DELETED. Binary byte sizes must be from 1 through 16. READ/WRITE are checked against the handle direction; character is the default; a probe needs no data handle.

This exact release boundary is smaller than later documents commonly called “the QFILE protocol.” The maintained System 303 protocol document adds directory, completion, property, and capability operations, and Genera's server grows again. Command counts are therefore meaningful only with a named source version.

Declared systems and their roles

This is a source-visible naming trap: “LFS” can mean the short display name of LOCAL-FILE or the actual later system whose nickname is LMFILE. The two have different representations, pathname rules, and protocols.

The older LOCAL-FILE

The older store models a disk configuration, directories, basic files, files, and links, with maps and page allocation. Attribute bits include closed, deleted, dumped, character, directory, do-not-delete, and do-not-reap state. Its access-path implementation describes itself as direct access to the file system on the current disk.

At method grain, the complete access surface is 20 operations:

This implementation's MULTIPLE-FILE-PLISTS is a useful example of UI pressure on the substrate: Dired can obtain properties for many displayed rows without opening or probing each file independently.

The hierarchical LFS/LMFILE

LMFILE treats directories as file nodes and supports a tree below a root. The implementation is split into pack/free-space management, block I/O, files, garbage collection, areas, nodes, name and hard links, PDP-10 compatibility, node changes, salvage, general and special directories, directory reading, completion, streams, and dump support. It is a store, not just a QFILE nickname.

The contemporary summary and source establish these user-visible semantics:

Several paragraphs in the contemporary LMFILE document are explicitly proposals: special mailbox/database node flavors, tree-wide compilation, richer forking, and some pathname syntax changes. They are not listed above as implemented features.

The two System 303 servers

FILE-SERVER listens on Chaos contact FILE and implements the control/data split expected by later QFILE clients. Its complete 18-branch direct dispatcher is:

The OPEN-FOR-LISPM, EXTENDED-COMMAND, and MOBY-CONNECTION branches are implementation extensions beyond the portable command set in doc/chfile.text. The public protocol document instead defines 15 portable names at its own boundary: DATA-CONNECTION, UNDATA-CONNECTION, OPEN, CLOSE, FILEPOS, DELETE, RENAME, CONTINUE, SET-BYTE-SIZE, LOGIN, DIRECTORY, COMPLETE, CHANGE-PROPERTIES, ENABLE-CAPABILITIES, and DISABLE-CAPABILITIES.

LMFILE-SERVER is a separate protocol. It listens on contact LMFILE; the RFC contains a user identity and first command. A connection owns one current file stream, and a second OPEN is rejected until that stream is finished. Control commands and file data share the connection, with packet opcodes separating command, reply, character data, binary data, EOF, node boundaries, and temporary lossage/winnage notifications.

At command-symbol grain, every server command installed in the active file2/server.lisp module is:

The catch-all STREAM-OPERATION forwards only operations the opened local stream advertised, and the probe stream exposes only properties/operations reported by the server. This is capability discovery, not an assumption that every LMFILE node implements every stream message.

The LMFILE-SERVER declaration names SERVER and MAISER as its MAIN module. The maintained tree also preserves an alternate file2/xserver.lisp with the same 29 command definitions and several implementation differences, but it is not the module selected by this system declaration. Source presence alone must not promote that alternate file to the active server boundary.

QFILE: retained legacy compatibility

Genera defines QFILE only over the Chaos medium. It preserves the separate control and reusable data-connection architecture and selects specialized access-path flavors for ITS, TOPS-20/Tenex, generic hosts, or another Lisp machine. The source retains the historical limits of three data connections for ITS and eight for ordinary remote hosts, while its LMFS-specific QFILE path permits 69.

The Genera server's complete 23-command dispatcher is:

This 23-name implementation inventory does not contradict the NFILE manual's comparison with an 18-command QFILE baseline; it demonstrates that “QFILE” changed between documented and implementation boundaries.

NFILE: the preferred marked-stream protocol

NFILE is registered as a FILE protocol over BYTE-STREAM-WITH-MARK, with a higher desirability than QFILE. Namespace service entries can offer it over Chaos or TCP; the generic network layer chooses the path, so ordinary operations such as Zmacs Find File do not expose NFILE as a separate application.

Commands and responses are typed token lists on a bidirectional control stream and carry transaction identifiers. File data uses separately coordinated data channels. Marks provide framing and resynchronization, and a suspended asynchronous-error channel must be continued or resynchronized before normal transfer resumes. The client supports reader-process, interrupt, and polling response paths, scavenges idle/unsafe channels, and has direct-access streams for partial reads or writes in addition to ordinary sequential character, binary, wide-binary, and bidirectional forms.

The installed NFILE reference and server source agree on this complete set of 25 commands:

The protocol's direct operations are significant. READ requests a byte range for a direct opening, ABORT interrupts that read, and DIRECT-OUTPUT binds or unbinds an output data channel. This is different from QFILE's normal whole-stream transfer and different again from an NFS remote procedure.

NFS: UNIX semantics behind the same file interface

The NFS client is a Genera file access path over UDP. It uses Sun RPC and XDR, chooses the highest usable protocol version registered for the host, maps UNIX-style pathnames, manages mount records, translates user/group identities, and adapts a largely versionless UNIX namespace to Genera's pathname/version conventions. A namespace service entry FILE UDP NFS makes the access path available; the public guide says it is preferred over FTP when so declared.

The protocol source's complete NFS version 2 procedure set is:

NULL, GETATTR, SETATTR, LOOKUP, READLINK, READ, WRITE, CREATE, REMOVE, RENAME, LINK, SYMLINK, MKDIR, RMDIR, READDIR, and STATFS.

The client also declares the version 1 mount operations NULL, MNT, DUMP, UMNT, UMNTALL, and EXPORT. These are protocol procedures, not Command Processor commands.

Source-visible cache policy is bounded and validation-aware: directory-handle and directory-content caches each hold 16 entries, the link cache holds 64, and their reap periods are five minutes. Mount entries also expire after five minutes of idle time and are unmounted by a timer. Directory entries are checked with modification and change times; updates invalidate cache entries if the update takes longer than the ten-second vulnerability window. These defaults explain why a Genera directory view can be responsive without treating NFS state as permanently authoritative.

There is an important media limit. The NFS user guide describes a symmetrical client/server product and names NFS Server. The inspected Open Genera source subset contains NFS-CLIENT and NFS-DOCUMENTATION system declarations, client modules, and server callback names in the shared protocol layer, but no NFS-server system or server implementation. The Genera 8.5 VLM release roster likewise names only NFS-Client and NFS-Documentation. Therefore:

• client architecture and the NFS wire contract are established here;
• the manual establishes that a Symbolics NFS server product existed; and
• the implementation and availability of that server in this exact Open Genera distribution remain a TODO, not an inferred feature.

LMFS on Open Genera

Genera's LMFS is the Symbolics native file system, not the same implementation or pathname syntax as the earlier MIT LMFILE. The remote pathname layer uses > as the directory delimiter and . for type/version syntax, supplies a meaningful root, and accepts the standard deleted/undelete semantics. Its source is useful for understanding remote LMFS names even when no local LMFS store is available.

For release 8.5, the source roster places full LMFS behind #-VLM; it is excluded from the Open Genera VLM release. LMFS-DEFSTORAGE, however, is a separately loaded development-utilities subsystem because other systems use its storage definitions. Seeing LMFS symbols or LMFS-DEFSTORAGE in the world therefore does not prove that the VLM has a local native LMFS volume.

Command-table structure

File System is the grouping area and has no directly defined commands in the inspected source. File and Directory are its two direct subsets. When the NFS client is loaded, NFS is added as a subset of File, so it inherits the ordinary file surface while adding two NFS status commands.

The following 25 commands are the complete direct-definition inventory. Optional systems matter: the compression commands require the Compression system, the source comparison and development commands require their development systems, and NFS commands require the NFS client.

Complete File area: 15 direct commands

Complete Directory area: eight direct commands

Complete NFS area: two direct commands

These two status commands do not limit NFS to two operations. Ordinary inherited file and directory commands operate through the NFS access path; the NFS area adds protocol-specific observation.