>>> I've been thinking of rewriting the name cache.  The changes I have
>>> in mind would allow you to always get the path for a file.
>> That sounds like a very drastic change [...]
>> Will you also be providing replacements for existing filesystems?
>> FFS, at least, has the "names are attached to links, not files"
>> model wired fairly deeply into its on-disk data structures.
> I'm sorry, but did you read the text you quoted?

Yes.  Did *you* read the text *you* quoted?

> Jason described a desire to re-write the name cache, which is an
> in-kernel entity.  I fail to see how changing it translates into
> changing (or needing to change) the on-disk format(s) of our file
> system(s).

Because arranging that files always have a path, and, what's more, have
a "the path", is a very fundamental change to filesystem semantics, one
that as far as I can see is incompatible with FFS on disk.  Regardless
of the means by which this end is achieved.  (He can't possibly create
the ability to "always get the path for a file" without, at the very
least, breaking the ability to have files with no paths naming them, no
matter what he is or isn't hacking on.)

> There are a number of times (see the stuff that got this thread
> started for instance) where we really need to be able to get a path
> for a file.

Well, I'm sorry, then you want something that is not very much like
Unix.  Unix simply does not support that operation, and never has; it
has always been possible to have files that have no paths at all that
name them.

> So we have a need now.  We have a developer expressing a desire to
> address that need.  I suggest we wait for code to be offered before
> reacting to details the not-yet-offered implementation may or may not
> posess.

Anything that satisfies the desire described - to always be able to get
"the path" for a file - implies a very deep change to the filesystem
semantics, and one that's incompatible with, at least, FFS - since in
FFS files don't have names; rather, links to files have names, and
there is no way quicker than searching the entire filesystem to find
another link if the one you have is unlinked, nor does the concept of
"the path" for a file make sense unless it happens to have exactly one
link.

Perhaps Jason meant "find a [not `the'] path for a file, provided it
hasn't been unlinked or renamed yet".  But that's not what he wrote,
and, based on what you write, it's not what you want, nor is it what he
wants (to be pedantic, what you think he wants; I assume you're
correct).  Perhaps Jason meant "find the path via which an open file
was opened".  Perhaps Jason meant "find the path to a file in almost
all cases, and we choose to let the facility using this break in the
cases where it doesn't work".  But those aren't what he wrote either.

What he *did* write seems to me to be fundamentally incompatible with
Unix filesystem semantics, including the basic design of the on-disk
data structures for what is probably our most popular filesystem.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B