Re: [OpenAFS-devel] AFS vs UNICODE

[Jeffrey Altman]

Erik Dalén wrote:

On Sat, Jul 19, 2008 at 5:13 AM, Jeffrey Altman
<[EMAIL PROTECTED]> wrote:

Erik Dalén wrote:

On Wed, Jul 16, 2008 at 9:38 PM, Jeffrey Altman
<[EMAIL PROTECTED]> wrote:
<snip>

All directory searches and file comparisons are performed by normalizing
the
input from Windows and the strings from the file servers prior to
performing
the comparison.   However, non-normalized strings are always delivered to
the operating system.

So, if you have an existing file in normalization D it is not possible
to write a file in normalization C but otherwise the same name?
(assuming it contains a composed character in the file name)

It doesn't matter what the normalization or lack of normalization.
The Windows client will only permit one instance to be created.

But the two copies could be created on a Mac and Linux client. Just
type "touch tëst" on both those platforms and you'll get two different
files.

Other platforms do not use Normalization for comparisons. They will screw their users.

But otherwise the windows clients use normalization C for files they
create, right?

The Windows client does not normalize what is written to the file server.
 It writes to the file server whatever was received from Windows.

But the default for windows is normalization C, right?

Windows does not normalize.  Its whatever the input mechanism produces.

If there is two files with the same name but different normalizations
will the windows client always open and write to the one with
normalization C?

No.  It will prefer an exact match and if that does not exist then it
will not permit either to be opened because the choice is ambiguous.
This is exactly the same behavior as is performed for case insensitive
matches.

Ok, so then it should be possible to open both, sounds good.

The Windows client code is correct. The question is how we are going to deal with this stuff for platforms where the process locale is not guaranteed to be UTF-8. We need to figure out

how ZFS which does Unicode normalization is handling this.

smime.p7s
Description: S/MIME Cryptographic Signature