macports-users Digest, Vol 167, Issue 5

[bunk3m]

Cesar,

Any thought of suggesting your change regarding normalization to 
rsync.samba.org/upstream?  I'm sure you (we) aren't the only ones who 
have such an issue.

I see that they have updated to 3.2.2 on Jul 4th from 3.2.1 on Jun 22nd 
so it is very active and as you mentioned rsync is used everywhere and 
essentially a standard.

Thanks for the very interesting question and Ryan and Jim for your 
explanations.  I learned a lot.

B.

On 06.07.2020 08:00, macports-users-request at lists.macports.org wrote:
> Message: 2
> Date: Mon, 6 Jul 2020 12:17:18 +0200
> From: Ces VLC <cesarillovlc at gmail.com>
> To: MacPorts Users <macports-users at lists.macports.org>
> Subject: Re: rsync and different UTF normalization in APFS vs HFS+
> 	(macports-users Digest, Vol 167, Issue 3)
> Message-ID:
> 	<CAM2WBq9OxnUtK_9EbWet3cO9Cwyd+TkMrFPZkh8xCCZ=FB=1VA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> On Sat, Jul 4, 2020 at 2:43 AM Jim DeLaHunt <list+macports-users at jdlh.com>
> wrote:
>>
>> [...] I hope you see the distinctions I'm trying to explain. And, I hope
> this helps you figure out a solution. Please let the list know what you
> find out.
>>
> 
> Thanks a lot, Ryan and Jim, for your messages and for the great information
> you provided. It's very complete, and, yes, Jim, what you described is the
> cause of the problem: rsync just transmits file names as verbatim raw
> sequences of bytes with no conversion at all.
> 
> IMHO, the correct way of fixing this shouldn't be by manually converting
> the encodings yourself with the '--iconv' flag, but actually with a flag
> for performing the check after normalization, which AFAIK doesn't exist (it
> wouldn't matter what normalization, just apply the same normalization to
> all file names before comparing them, and then discard the normalization).
> What I mean is, what's the purpose of rsync considering as different two
> files whose name is identical when being displayed in a terminal? Two
> identical text strings can be normalized in different ways (for example:
> accents in separated codes, or in composed codes), but they are the same
> text. So, if the text is the same, why consider them as different file
> names?
> 
> I don't understand why such '--normalize-before-compare' flag doesn't exist
> (I insist: no need to specify the normalization algorithm, just apply the
> same algorithm to all file names). It would fix all these problems in an
> elegant and clean way, and, BTW, this would be the behaviour everybody
> expects, if I'm not missing any point here.
> 
> Another surprising thing is that I don't see any serious alternatives to
> rsync. It's good because if everybody uses rsync, it will be better tested
> and more reputable, but it also has the bad side of what happens when it
> doesn't support the feature you need...
> 
> Kind regards,
> 
> C?sar