[OpenAFS-devel] AFS vs UNICODE

[John Hascall]

> 
> Derrick Brashear wrote:
> >>  Note that the problem is worse than might be inferred from your
> >>  description.  If a fileserver is installed which behaves as you suggest,
> >>  then when a MacOS X client creates a file with a name for which NFC and
> >>  NFD produce different code sequences, the fileserver will normalize to NFC
> >>  before creating the directory entry, and MacOS will be unable to look up
> >>  the entry in the resulting directory.  It'll be subtle, too, because the
> >>  MacOS client will update its local copy of the directory itself, with the
> >>  NFD filename, and won't notice the fileserver's change until either that
> >>  directory is changed by some other client or the directory data is evicted
> >>  from the MacOS client's cache (note that callback expiration is _not_
> >>  sufficient here -- the client can use "old" data in its cache as long as
> >>  it does a new RXAFS_FetchStatus and notices the DV hasn't changed).
> > 
> > I'm thinking there's a trick to be done with an "unexpected" DV change
> > such that LocalHero doesn't apply, avoiding this issue and forcing a
> > refetch.
> 
> I still don't think that is going to do the right thing.
> That will permit the old MacoS X client to create the file.  It will
> read the directory with the new name in it.  And then be unable to open
> it because NFD != NFC and the hash table lookup will fail.
> 
> I'm so sad.

Would it work for the server to do essentially:

    nfc = toNFC(name);
    if (lookup(nfc) == WIN) return goodness;
    nfd = toNFD(name);
    if (differ(nfc, nfd)) {
        if (lookup(nfd) == WIN) return goodness;
    }
    return sadness;

    and probably also refuse to create any file
    where toNFC(name) == toNFD(fromNFC(existing))
    for any existing file to prevent conflicts

John