Re: DIRECTORY behavior with /= implementations

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.)

But in any case, operating systems come and go, and might still have
done so. For the standard to have mentioned a specific file system in
a way that required behavior (rather than, as happens now, merely to
illustrate the option to vary) it would have been for the standard to
doom itself to being unusable in a small number of years.

If the standard had said file-system specific, that would imply that
no conforming implementation could exist on a platform without a
standard in place for its file system. That would be an undue burden,
not to mention probably doing things in the wrong order, since good
standards usually come after implementation+use, not before.

Keep in mind, too, that what implementation survived was in part a
product of what answers vendors made to these questions in order to
make their product useful. For the standard to decide when there was
legitimate and active controversy in the market risked that the
standard would doom otherwise viable implementations. The vendors on
platforms where there were multiple implementations actually needed
the flexibility to disagree precisely because these were not settled
matters.

It also is not clear what "standard" would mean beyond the standard.
Would ANSI CL saying there had to be a way of specifying it per file
system mean it was ok for there to be a de facto standard? An IEEE
standard? Would an existing conforming implementation be suddenly
non-conforming if someone came out with a new implementation on the
same file system that diverged?

The standard says what is necessary to say: that it cannot control
truth beyond its own walls. The contributors to the standard, to
include myself as editor, knew that it was possible for there to be
file-system specific layered standards on of popular platforms, and
that on obscure platforms it would not matter that there was
standardization. So we left it blank, and left it to markets and
interested communities to sort out the lines of aggregation for
partial layered standards. It might be nice if the universe were
other than it is. But the standard works within existing physics.

So I stand by that particular word choice, even if I'm easily willing
to believe there are other ill-chosen wordings all around it. :)
.

Relevant Pages

  • Re: Running Standalone Lisp Programs
    ... On platforms without a command line ... into the ANSI Common Lisp standard is a very problematic venture. ... > for not including file system operations in the CL standard. ...
    (comp.lang.lisp)
  • Standard and COBOL file formats (was: Report enhancements)
    ... RW> I'd say a Cobol compiler that cannot read a sequential file written ... is using a non-standard file format. ... set up his own file system, which is the standard file system of his ...
    (comp.lang.cobol)
  • Re: future C standards
    ... Those functions have no business in a no file system C implementation. ... implementation needn't support, or any other standard header ... required only for hosted implementations, i.e., ones that already must ...
    (comp.std.c)
  • Re: Fixing Posix semaphores
    ... > even though it technically qualifies in a somewhat ... > the standard places ... > the semaphores directly in the file system, ... pathname is not mandated by the std. ...
    (freebsd-hackers)
  • Re: Magic Number for New File system
    ... > We are planning to write a new file system for our requirements. ... There's no standard place to put a magic number, ... location of the superblock will vary from filesystem to filesystem, ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)