[ Responding to the last post, but really to the entire thread. ]

Thank you all for this wonderfully erudite discussion. I spent quite a while just now reading over the entire thread. I'll summarize the things I got out of it --

We have come to treat file "names" as intrinsic properties of the file "nodes", while in fact they are properties of the arcs from directories. Thus really, I would like my filesystem to tell me that some given file is called --

  "Pepsodent Advertising Revenue Report"

and is known by the name --

  /home/ihab/docs/pepso/ads.doc

All modern document editors have a "Title" field. How many of us fill it out completely as soon as we open a document? Show of hands? ;) ... Right. We rely on the path to disambiguate. As long as we continue to do this, I have to agree at least to some extent with MarcS that we have no recourse but to treat the path as -- if not essential information -- then at least *helpful*.

At this point, I need to remind myself that I am talking about taming a traditional filesystem. If we were building a new persistent object system from scratch, then Kevin Reid's remarks about building a "history" tracker to keep track of objects and annotate them with context would apply, and I think we should throw out all this mess we have now and start over.

MarcS mentioned Google Docs and Spreadsheets as an example of something that builds its own naming scheme, more or less. Actually, Google Docs indexes the "Title" of the document; its internal identifiers are machine generated and cap-like. For example, in my Google Docs, I have two documents titled "Foo" right now:

  http://docs.google.com/Doc?id=dfgxb7gk_64g2czqgg6
  http://docs.google.com/Doc?id=dfgxb7gk_639z5xfsfh

They both show up by their title, "Foo", in the UI. I don't know what the product managers of Google Docs would say about this, but if I were to channel them, I'd say, "This is Google -- search!"

MarcS mentioned that it is unlikely for files to contain secret information. Yes, for the common case that is true, but. There are many of file names in proprietary server apps that would be disastrous (or at least embarrassing :) if leaked.

David-Sarah's point about <DirectoryEntry> vs. <File> is a good one. An equivalent suggestion is from MarcS, regarding the ability to "makeOpaque()" a file, thus "orphaning" its path in the directory hierarchy; essentially, a "chroot()". Except David-Sarah's scheme is _prix fixe_ while MarcS's is _a la carte_.

In the setting in which this problem is most urgent, we wish to endow a JavaScript module sandbox, per the Securable Modules proposal of ServerJS:

  https://wiki.mozilla.org/ServerJS/Modules/SecurableModules

with some reference to *something*. Having read over this thread, I think a pragmatic solution would be if:

* Files provide no "getParent()";

* Files provide a "getPath()" up to the closest makeOpaque()-ed directory; and

* Each sandbox gets a reference to a (usually -- but not always -- makeOpaque()-ed) reference to a directory that serves as its "chroot()-ed jail".

Does that sound reasonable?

Ihab

--
Ihab A.B. Awad, Palo Alto, CA