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


   From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

   I don't know what you mean by hopeless.  It's worth having it written
   up for the record.  At least then it's on file as something to be looked
   at again for a later standard.  And it's got the option of becoming a
   de facto standard in the interim.  And, it might conceivably get added
   this time.   After all, what would be the downside if it were added.
   Are the other file-related facilities any more solid than what you're
   describing.  A lot of them have lots of ways they can fail, but mostly
   they do fine and people are happy to have them...

I agree with Kent that at the very least we should track the issue and
see where it leads.  I am not so sanguine that we will actually arrive
at a writeup.

I identified a couple specific loci of gotchas on the phone with JonL.
Although the CL pathname spec manages to accommodate nearly every
known file _naming_ system, it missed two other important attributes
of files.

 links - The condition that two pathnames lead to the `same' file even
though they are textually different.  This isn't a new concept in Unix
(hard links have been around since the beginning) but the more recent
symbolic links and network file systems are serious omissions when,
say, writing a _real_ defsystem.  A real defsystem ought be able to
compile parts of a system on different days using different hosts, and
almost never report "definition foo from file /a/x/y/z.lisp is being
redefined by file /w/x/y/z.lisp."  This is a tricky problem that CL
has no real business addressing, but the language could provide a
little more help than it does.  For instance, probe file ought have a
way to return the file type of the probed file -- as a keyword second
returned value?  :FILE, :DIRECTORY, :SOCKET, :SYMBOLIC-LINK, etc.  The
set of possible types can't be closed by the spec, of course.  Perhaps
three return values would be warranted: the second would be from a set
defined by CL and the third would allow for implementation extensions.

 permissions - Most modern file systems have file protection.  On some
file systems the creator of a file can specify some or all
permissions, and some allow protections to be changed dynamically.
Somehow CL has survived by creating all files with whatever
protections the environment provides by default, and I'm not aware
that anyone has ever complained.  But when it comes to creating
directories, the question of getting the permissions right seems
somewhat more important, because the wrong protection might prevent
subsequent creation of files in the directory, or creation of
subdirectories, or whatever.  There are more ways to lose.