Re: DIRECTORY behavior with /= implementations

pjb@xxxxxxxxxx (Pascal J. Bourguignon) writes:
Kent M Pitman <pitman@xxxxxxxxxxx> writes:
Thibault Langlois <thibault.langlois@xxxxxxxxx> writes:

The mapping of the pathname components into the concepts
peculiar to each file system is implementation-defined

OK thanks for your answer. We all have to live with that.
Nevertheless I think it would be more understandable if it was file
system-specific instead of implementation-specific.

I'm not sure this is literally true. One might get some warm fuzzy
from such wording, but after a while one would ponder about what that
fuzzy wording meant.

For example, I'm not sure to what extent Linux existed at the time of
the standard went out. (I don't recall the "feature freeze" date, but
it was a a few years before the final version--perhaps as early as
1988. We made essential changes after that up to publication time, but
it was hard to make such changes.)

Not Operating System, but File System.

Note that the CLHS's definition of "file system" permits different
interpretations:

file system n.
a facility which permits aggregations of data to be stored in named
files on some medium that is external to the Lisp image and that
therefore persists from session to session.

And "file" is defined as

file n.
a named entry in a file system, having an implementation-defined
nature.

Consequently, it would be conforming for an implementation to define
"file" in such a way that any of the following would count as "file
systems" for the purposes of that implementation:

* a network protocol that supports naming, storage, and retrieval of
data, provided there is some medium backing the protocol,

* a format for laying out data on some medium, given that the layout
supports naming of data units,

* a namespace (a "VFS") presented by some host's operating system or
library,

* a relational database schema that associates data with names in some
manner.

(Other things are possible, too.) Consequently it's not right to
suppose that "file system" in the CLHS to describes only one of the
categories above; the term is more expansive than that.

And it's even worse than that: mount options may intervene. For
example, when you mount an ISO-9660 file system on Linux, you get a
subdirectory tree where you have files with names in 8.3 with a
version number! That is, unless you have some unix or "Joliet"
extension which gives you normal file names, but you can still give
options to mount to see it without these extensions.

Another example would be MacOSX, where the default file system with
the default options is not case sensitive, but where you still can
mount "normal" unix file systems that are case sensitive.

I think these two paragraphs highlight the difference between two
senses of "file system", either of them conforming with the CLHS:
ISO-9660 and Joliet are or formats, while the behaviors of some Unix
host's namespace is an instance of a VFS. The upshot is that some
propositions turn out to have different truth values under different
senses of "file system":

-- The Unix file system supports hard links.

This is true for "file system" if you're talking about customary
Unix disk formats, but not in the VFS sense, inasmuch as most
modern Unixes can mount volumes having formats that cannot
represent hard links (e.g., FAT).

-- Modern file systems do not support wildcard file specifications.

Depending on what one means by "support", this can be true about
formats or an operating system's VFS, but false for other
definitions of file system (e.g., talking to a host via some
protocol that includes wildcards, e.g., FTP).

So I think it's worthwhile to be careful to avoid equivocation when
thinking about these issues. (I don't think you are equivocating, but
discussions of this stuff can get mired in these semantic problems,
sometimes because people don't notice that they're not using terms the
same way.)

So, even in a given Operating System, you may have serveral File
Systems with different properties, and different mapping to the OS API
for FS access.

ISTM that for Lisps that aren't operating systems, it's the Lisp
implementator, not the operating system, who gets to decide what "file
system" means for that implementation -- and I think this aspect of
the language was by design.

--
RmK
.

Relevant Pages

  • Correlated AIX 1.2.1 and 1.3 900 series error messages
    ... 900-008 Bad file system allocation detected ... Record all information and follow your local procedures for reporting software problems. ... The operating system requested deletion of a mount entry that is not in the current mount table. ...
    (comp.sys.ibm.ps2.hardware)
  • Re: For Mitch and Alan.
    ... That's not an operating system. ... Controlling accesst to the file system is not the same thing as being the ... The same way it communicates with any application, resource, or process. ... It is relevant as an example of something that Microsoft failing to ...
    (comp.sys.mac.advocacy)
  • Re: For Mitch and Alan.
    ... That's a feature that Microsoft told everyone was going to be in the ... Controlling accesst to the file system is not the same thing as being the ... was pretty much the first task delegated to an operating system. ... That's still completely irrelevant to the issue of driver testing for ...
    (comp.sys.mac.advocacy)
  • Re: For Mitch and Alan.
    ... That's a feature that Microsoft told everyone was going to be in the ... Controlling accesst to the file system is not the same thing as being the ... was pretty much the first task delegated to an operating system. ... The same way it communicates with any application, resource, or process. ...
    (comp.sys.mac.advocacy)
  • Re: Mac OS X use versus Windows XP use...
    ... It shows it's part of the file system, ... system-wide spell-checking are applications. ... So where is the spell checking binary, Edwin? ... "No one uses an operating system, and all the things you claim are ...
    (comp.sys.mac.advocacy)