On Tue, May 6, 2008 at 4:57 PM, Jeffrey Altman <[EMAIL PROTECTED]> wrote: > 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. > >
The git list had a discussion about this same issue, and from their testing is seems like most other file system drivers for Mac OS X translate between UTF-8 NFD and NFC. According to this post at least SMB, MSDOS, UDF, ISO 9660 (Joliet), NTFS and ZFS file systems do this. HFS+ stores the files in NFD natively. http://kerneltrap.org/mailarchive/git/2008/1/23/593749 Another subtlety is that they use different types of NFD in Mac OS X < 10.3.0 and >= 10.3.0. Lots of fun in other words, but as most other file system drivers does it it seems logical to do it in the AFS client for Mac as well. -- Erik Dalén _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
