[OpenAFS-devel] AFS vs UNICODE

[Jeffrey Hutzelman]

On Tue, 6 May 2008, Jeffrey Altman wrote:

> The real problem with this problem is that once the new file server is
> deployed and the salvager is run against the volumes the existing MacOS
> X clients will fail to be able to read any files in AFS.   If anyone has
> an idea of how to address the Unicode normalization problem going
> forward that doesn't result in an interop failure for existing clients,
> please say something.

I believe we discussed this issue when we designed extended directories
way back in... 2005?  Old MacOS X clients here need to be treated in the
same way as other legacy clients, getting an old, unmodified directory
structure.

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 need to think about your problem description and proposed approach in
more detail.  I also need to think about how it interacts with extended
directories, whether we can/should reject the extended directory approach,
and if not, whether an interim solution is possible that doesn't just make
the problem worse, or make deploying extended directories infeasible.  I
do have some thoughts in this area, but need to let them gel a bit.

-- Jeff