macports-users Digest, Vol 167, Issue 5
bunk3m at gmail.com
Mon Jul 6 18:02:02 UTC 2020
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.
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)
> <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>
>> [...] 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
> 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,
More information about the macports-users