Re: Differences that aren't ?

"Head Geek (伟思礼)" <[email protected]> writes:

> WGroleau@MBP ~ % head -4 .unison/Countries.prf
> # Unison sync for Countries/Contries
>
> root = /Users/WGroleau/Countries
> root = /Users/WGroleau/Contries

You left out the rest.  I realize you might have your reasons, but it's
hard to know what's going on.  Perhaps you can create a minimal
reproducer.

> Only in Countries/AX: Åland_Islands.info

> Apparently unison reads composed characters on one side and decomposed characters on the other and considers them the same.
> "A    ̊  **   l   a   n   d "   vs   " Å  **   l   a   n   d"   in the above

macOS considers upper/lower case sort of the same, and I don't know what
it does about unicode representation.  I don't know what the unicode
specs say.  It could well be that they are supposed to be treated as the
same, as it seems that logically they are.  Rhetorically, what would
happen when syncing between a filesystem that stores filenames as utf-8
and one that uses uncompressed 32-bit unicode?

You didn't explain how you got to this situation, and that's part of why
I brought up a repro script.  unison is, after somehow having varying
encodings on the file systems (it's not clear written by what program),
and previous syncs, not detecting a difference.  But that's not the
whole story.

Overall, besides trying to create a (minimal) repro script, I'd suggest
understanding:

  on macos, whether filenames are just non-NUL bytes, as they originally
  were on UNIX, or utf-8, or something else.

  unicode's view of what is supposed to be considered equal

  unicode's view of normal form when writing, and the degree to which
  denormalized is perfectly ok vs not-really-ok-but-tolerated.

  ocaml's take on implementing unicode rules.


You may want to read src/unicode.ml.  It looks like there is code, to
deal with combining characters, that seems likely to be normalization.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].