nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Question on compath() in sbr/path.c


From: Mike O'Dell
Subject: Re: [Nmh-workers] Question on compath() in sbr/path.c
Date: Mon, 31 Jan 2005 23:26:49 -0500

there are two ways to do filenames

one is purely as text strings which can admit
a number of algebras, one of which provides for
having dot-dot reflect the temporal state which
the current string to be what it is, and all
name operations are done with string algebra.

the other way is using a directed graph as 
the implementation.  the Unix filesystem
works this way. dot and dot-dot are implemented
as explicit pointers to directory inodes.
if the directed graph (directory graph) is used
to evaluate dot-dot, the parent is the one
reflected in the graph.

there is no "right" answer - one can argue that
in some cases one is more consistent than the other.

if dot-dot is to be recorded in the filesystem, then
its value cannot be context-sensitive based on the
computation history of the process.

if dot-dot is evaluated with string algebra, like
is done with many shell "builtin" cd functions,
then the value of dot-dot can indeed be context-sensitive
and reflect whatever is desired. the usual context
is the temporal sequence of "cd" operations done by
the shell to get to a given directory.

this is *precisely* the same discussion as hard-links vs soft-links
(aka "symbolic links")

hard-links use references counts so provide semantic
persistence. soft-links use string algebra and hence
are subject to the dangling-pointer problem.
hard-links are difficult to implement between filesystems,
soft-links span filesystems easily but cannot implement
"retain until exit" behavior for filesystem objects.

the simple fact is they do very different things and while
they appear to have some functional overlap, there are cases
that each can do that are essentially impossible for the other.
same with how "dot-dot" is done and for the same reasons.

having been there when symbolic links were introduced,
i cannot imagine a system without both of them. the loss
of either is a significant impediment.

        -mo





reply via email to

[Prev in Thread] Current Thread [Next in Thread]