Re: port-filename and path canonicalization

[Thien-Thi Nguyen <ttn@gnuvola.org>]

() ludo@gnu.org (Ludovic Courtès)
() Thu, 22 Apr 2010 00:26:43 +0200

   > That is, if a file port supports ‘file-port-directory’, then how
   > to use/restrict the resulting object is left up to higher layers,
   > where it belongs.

   I would put it the other way round: if an application wants to
   implement ‘file-port-directory’, then it’s its responsibility
   to associate the necessary information (and authority) with
   open file ports (those under its control, that is.)

   It’s an application of the principle of least authority.

Sure, given the model that access and authority are equivalent.
My point is that it is possible to use a model where they aren't.
A system that supports the latter model can build the former on top.
But a system that supports only the former model can only fake the
latter model, later.

It's always easier to combine separate things later than to
separate conflated things later.  The canonicalization wranglings
highlight this.

Canonicalization is a high-level concept needed because the
low-level access was not granular enough.  A filename with
directory components of an already validated (opened, accessed,
processed in the Right Way) file implies that all the parent
directories have also *already* been validated (in their own way).
But that, and related, information is lost, so we need to
canonicalize in order to re-validate those portions.

If that directory information is saved (simple internal caching),
these particular recomputations are avoidable.

If that directory information is available to the application
(reified and appropriately sanitized), the application can layer
authority measures as it sees fit (as you state in the first
paragraph, IIUC), in addition to enjoying the efficiency gain,
and the need for canonicalization disappears.

(Actually, the need for canonicalization disappears even with
simple internal caching, but since the context of this discussion
is process B finding neighbors to a file created by process A,
it is no longer an internal matter.  Or perhaps that's just me
jumping ahead (i've got bugs, debuggers and debugging file formats
on the mind lately)?)

OK, back to the grindstone.  I'm digging my way out RCS duties
(one might view this as preparation for History Objects ;-) right
now, but hopefully will be able to transform word spew to code
spew (for Guile) in the next several weeks.

A last parting word/pointer on this thread re "path":
 (info "(standards) GNU Manuals")

thi