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.
smime.p7s
Description: S/MIME Cryptographic Signature
