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

Re: ILA-NFS



         Date: Mon, 23 Jan 89 14:59:40 -0500
         From: andrew@linc.cis.upenn.edu


     	    Posted-Date: Fri, 20 Jan 89 19:43:16 -0500
     	    Date: Fri, 20 Jan 89 19:43:16 -0500
     	    From: andrew@linc.cis.upenn.edu

     	    We have had some problems with file-name translations and have
     	    had to make some changes in the way logical and physical
     	    pathnames are parsed.  Specifically, we've had to change
     	    logical names so that all case information is retained (instead
     	    of upcasing by default).  Also, the flavor LOWER-CASE-PREFERRED-MIX
    IN
     	    which is mixed into unix pathnames is broken.
     	    (try (send #p"<unix-host>:/foo/foo.lisp" :new-name "bar")
     	    (send #p"<unix-host>:/foo/foo.lisp" :new-name "BAR")
     	    (notice the case inversion)

     	    We've fixed this to work properly along with allowing things
     	    like README to be accessed (names with all caps).

     	 This case-inversion behavior is fully documented, not a bug.  It is
     	 described in the "Streams, Files, and I/O" manual; look for
     	 "interchange case".  The purpose is to make things like

     	    (copy-file "<VMS-host>:[DIR]FOO.LISP" "<unix-host>:/dir/")

     	 work as expected (i.e., the result file should be named "foo.lisp",
     	 not "FOO.LISP").  The :NEW-RAW-NAME message is intended for your
     	 purposes.

         I don't think that you caught the whole point.  The flavor in which
         the above inversion occurs in called LOWERCASE-PREFERRED-MIXIN,
         implying that things in uppercase will translate to lower. The
         bug is that when this flavor is handed things in lowercase,
         they are translated to upper.  This behavior is not at all desirable,
         and is something I call a bug.

     I caught the whole point; I've explained this confusing feature to many
     people over the years.  I also understand the problems it causes; we've
     got a "portable" file manipulation package whose biggest problems have
     been caused by the different ways in which Common Lisp implementations
     perform pathname operations, and case is one of themost insidious
     differences.  Yet I still maintain that Symbolics has done things in the
     best way for an implementation that supports a heterogeneous file
     system.

     Please read pages 71-73 of "Streams, Files, and I/O".  When using
     non-:RAW operations, uppercase components represent the file server's
     preferred case, lowercase components represent the opposite case, and
     mixed case components are left alone.  In the case of file systems on
     which lowercase is preferred (such as Unix), this means that the
     non-:RAW operations (which include the Common Lisp pathname functions)
     toggle the case of monocase components.

     Note, by the way, that everything is still kept consistent in this
     system:

     	(pathname-name "<unix>:/foo/bar.lisp") => "BAR"
     	(send #p"<unix>:/foo/bar.lisp"
     	      :new-name (pathname-name "<unix>:/foo/quux.bin"))
     	  => #p"<unix>:/foo/quux.lisp"

     You only run into problems when you try to cons pathnames from strings
     that didn't originate in the pathname software, e.g.

     	(let ((new-name (accept 'string :prompt "New name")))
     	  (send pathname :new-name new-name))

     In this case, it would probably be more appropriate to use
     :NEW-RAW-NAME, since users don't generally type in interchange case.

Ok, I see your point but the scheme doesn't work.  Suppose I have
a defsystem form and I have a short-name attribute "foo". If this
system is stored on a unix host with a physical default pathname,
the system will try to look for files of the form
FOO.system-dir, etc.., instead of foo.system-dir.  Thats not at
all what I expect, nor what is stored on the unix machine.
  This problem manifests itself in many different forms, in
places where none of my code is responsible for sending parsing messages
to the pathname. Why shouldn't LOWER-CASE-PREFERRED-MIXIN do exactly
what it says?