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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
