How can I rename files in LMFS just to change the alphabetic case?

["Robert W. Kerns" <RWK@scrc-yukon.arpa>]

The answer to the subject line is that, so far as LMFS is concerned,
if it only differs in case, it differs not at all.

    Date: Wed, 2 Dec 87 10:26 EST
    From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
	Date: Tue, 1 Dec 87 17:26 EST
	From: Roland Zito-Wolf <RJZ@JASPER.Palladian.COM>
    
	    Date: Tue, 1 Dec 87 09:44 EST
	    From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
	    It's not really a "bug" in the sense that you are thinking.  The root of
	    this behavior is that parsed pathnames are interned.  There has been a
	    longstanding debate about whether or not they should be interned, which
	    I will not go into here.
    
	    There is a way to bludgeon around this, but it is fraught with potential
	 danger, so I won't say what it is.
    
	I've wondered about this too. How about if you put in a method to change the
	filename string, under the restriction that the new filename would be string-equal
	to the old one, ignoring case? Would
	there still be cases where this would damamge something?
    
    "No comment"

OK, I'll comment.  No, it wouldn't damage anything.  It wouldn't
fix anything, either, unless you managed somehow to invoke it both on
the local host and the server host.

Let me also point out that the main reasons pathnames are interned
is so that you can 1) efficiently compare them (minor reason) and
2) do 1:putprop0 on them (major reason).  A secondary issue is storage
efficiency, if you're going to have multiple pathnames.

With current technology, I suspect it might be possible to stop
interning and maintain the ability to do 1:putprop0 (which the system
depends on heavily).  I suspect the main storage issues could be handled
by having 1:canonical-pathname0 return a canonical copy, as well.

However, the performance issues are a little too involved to evaluate
completely off the top of my head.  And there would definitely be the
compatibility issue of not being able to compare pathnames with 1eq0.

Another requirement would be that 1equal0 be extended to allow type-
specific comparisions of instances, since Common Lisp specifies that
1equal0 works on pathnames.