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

[Jeffrey Mark Siskind <Qobi@zermatt.lcs.mit.edu>]

        There seems to be some very annoying behavior in LMFS regarding alphabetic
        case in files names.

    SWM@sapsucker.scrc.symbolics.com writes:

    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.

I disagree. It is a bug. One must make the classic distinction between policy
and mechanism. It is true that the mechanism of interning does correctly explain
the behavior. The policy however is misdesigned. Policy should drive the mechanism.
Mechansim should never be used as an afterthought to create or justify policy.

    There is a way to bludgeon around this, but it is fraught with potential
    danger, so I won't say what it is.

    barmar@think.com writes:

    From page 102 of "Streams, Files, and I/O" (book 5 of the Encyclopedia
    Symbolicorum): "Due to problems with interning of pathnames it is
    sometimes difficult to control the casing of a LMFS pathname, and it is
    almost always impossible to change it once established."

    Pathnames are interned both on the local machine and on the file server.
    Interning is necessary to implement pathname equality checking and to
    allow properties to be associated with pathnames.  I doubt your problem
    will ever be fixed.

I realize that they are interned. But what is needed is a version of
RENAME-FILE that takes only a string and not a pathname as the second
argument and does not immediately parse that string into a pathname
but rather bypasses the pathname interning mechanism and goes directly
to LMFS to change the file name. Ideally, then, it should go and
update any already interned pathnames, on both the local host and
the file server, to reflect this change. I generally agree with the
policy that 1) case should be insignificant when comparing pathnames for
equality and that 2) the file system should remember the case of the
first mention of any given pathname. The present interning mechanism
effectively implements this policy. The only place I can think of where
this policy is misdesigned and inappropriate is when renaming files.
In fact, I can't think of any use for the original RENAME-FILE protocol
which allows an already interned pathname as the new-file argument.
What RENAME-FILE should do instead is parse (and merge) its second
argument in case sensitive mode, irrespective of the case sensitivity
of the host, and then later structure forward the old pathnames to the
new ones.

I don't think that anyone can argue that the present functionality of
file renaming is desirable, just that it may be difficult (but not
impossible) to fix. I hope that it is not too difficult and that
this problem is fixed sooner than barmar@think.com thinks.