Error on umlauts when syncing 2 macs

Get help for specific problems
Posts: 7
Joined: 11 May 2023

ApB1

I am using FreeFileSync to synchronize files with two identical MAC computers.

Both MACs are:
MacMini M1 (Silicon)
macOS Ventura 13.3.1 (a)
16GB RAM
HDDs formatted with APFS
Network over Ethernet with SMB sharing,
(AFP SERVER functions have been removed by Apple)

When I synchronize files between "MAC A" and "MAC B"
(i.e. FreeFileSync is running on "MAC A")
then "MAC B" cannot OPEN files which have German umlauts (ä, ü, ö) in the file name.
Also in the parent directories there must be no German umlauts. (ä, ü, ö)

If I get files from "MAC B" to "MAC A" in the same sync process, files with German umlauts can be opened on "MAC A".

So FreeFileSync treats file and folder names differently:
Sent files CANNOT BE OPENED on the destination MAC (MAC B) if umlauts are present.
But on the MAC where FreeFileSync is running (MAC A), received files with umlauts can be opened.

If the not working files are renamed manually,
i.e. existing ä,ü,ö are exchanged for ä,ü,ö entered via keyboard
in the same place, then you can open these files again.

However, umlauts must be replaced both in the file and in all folder levels above it.

I have not noticed any problems with other special characters so far.

Can there be a solution for this problem?
User avatar
Posts: 4867
Joined: 11 Jun 2019

xCSxXenon

This sounds like an issue with MAC B before anything else. MAC B can't open any files with the umlaut in the path?
Posts: 7
Joined: 11 May 2023

ApB1

No,
"MAC B" can open all files with umlauts except those that have been synchronized from "MAC A", on which FFS is running, to "MAC B".
If I run FFS on "MAC B" and synchronize the same files from "MAC A" the umlauts work on "MAC B
But when I do it this way, files with umlauts from "MAC B" do not work on "MAC A".
(And, as already described, umlauts must not be in either the pathname or the filename.)
Posts: 1202
Joined: 8 May 2006

therube

What version of FFS?

12.2 had "Fixed drag and drop for non-ASCII folders (macOS)" (& maybe that is interfering ?)
Posts: 1202
Joined: 8 May 2006

therube

If the not working files are renamed manually,
i.e. existing ä,ü,ö are exchanged for ä,ü,ö entered via keyboard
in the same place, then you can open these files again.
So you simply replace ä, in place, with ä, & it works?
(To me, that makes no sense what so ever. Unless...)

Unless (& I know nothing of Mac, nor AFPS or AFP or SMB ;-)), but may this be playing in:
You may need to tweak some settings to keep sharing volumes after upgrading to High Sierra or later.?
Posts: 7
Joined: 11 May 2023

ApB1

Yes, i simply replace the ä,ü and ö with ä, ü and ö and then is everything OK.

It seems that when transferring filenames and paths the encoding of the character set changes, but only when sending from FFS to the other MAC, when receiving on the device where FFS is running the encoding seems to stay the same.
Posts: 7
Joined: 11 May 2023

ApB1

What version of FFS?

12.2 had "Fixed drag and drop for non-ASCII folders (macOS)" (& maybe that is interfering ?) therube, 11 May 2023, 17:52
I always use the latest Version via autoupdate.
User avatar
Site Admin
Posts: 7506
Joined: 9 Dec 2007

Zenju

This is a known and ancient bug of macOS. Not sure why Apple doesn't fix it. Presumably, because they want to push their own AFP as a network protocol rather than properly support SMB which Windows is using.

SMB sharing case-sensitive or NFD file names is fundamentally broken on macOS:
=> the macOS SMB manager internally buffers file names as case-insensitive and NFC (= just like NTFS on Windows)
=> test: create SMB share from Linux => *boom* on macOS: "Error Code 2: No such file or directory [lstat]"
or WORSE: folders "test" and "Test" *both* incorrectly return the content of one of the two
=> Update 2020-04-24: converting to NFC doesn't help: both NFD/NFC forms fail(ENOENT) lstat in FFS, AS WELL AS IN FINDER => macOS bug!
Posts: 7
Joined: 11 May 2023

ApB1

But why can I copy or move files and folders with umlauts from "MAC A" to "MAC B" and from "MAC B" to "MAC A" over the network with the macOS interface (Finder) without any problems?

I have these problems only with FFS and only on the "passive device", i.e. the "receiving device" when syncing.

Received files and folders with umlauts work perfectly on the "active device", on which FFS is running.
Posts: 7
Joined: 11 May 2023

ApB1

Between Windows 10 and the MACs, there are problems with file names from time to time via the network shares,
if they are on the PC, they have to be renamed on the PC, on the MACs they cannot be renamed over the network.
But this does not affect all files with umlauts.
I sometimes suspect that it has to do with the encoding of the mails (on the Windows 10 computer) with which the affected files arrived with us.
Posts: 7
Joined: 11 May 2023

ApB1

But why can I copy or move files and folders with umlauts from "MAC A" to "MAC B" and from "MAC B" to "MAC A" over the network with the macOS interface (Finder) without any problems?

I have these problems only with FFS and only on the "passive device", i.e. the "receiving device" when syncing.

Received files and folders with umlauts work perfectly on the "active device", on which FFS is running. ApB1, 12 May 2023, 08:22
Sorry, with macOS interface (Finder) does not work either. So the error comes from the Apple operating system after all.
We have copied files very much and often via the Finder but apparently always (mainly) files "fetched" and not "sent". So, unfortunately, I first noticed the error when syncing with FFS, since files are always sent AND received during the sync process.
User avatar
Posts: 4867
Joined: 11 Jun 2019

xCSxXenon

At least we confirmed where the root issue is! You may just have to have a FFS setup on each that 'fetches' from the other and never sends