Syncing from NAS to MacOS High Sierra

[Freeze23]

Hello,
so far, I synced my Synology NAS to my PC with Windows 10 without error.

Now I've tried this under MacOS High Sierra and get the following error message in about 60% of the same files:

Error code 2: No such file or directory [lstat]

Please see attachment / photo.

I hope someone can help me, since I have long searched for a good synchronization program and I would like to continue to use FFS.

Many Thanks!

[Zenju]

This seems to be a Unicode normalization issue (macOS uses decomposed, while other OSes use precomposed). On macOS FreeFileSync converts filenames to decomposed as recommended by Apple. This generally works fine until talking with non-Apple devices like in this case a NAS.

[Zenju]

This issue should be fixed with the improved path handling as of FreeFileSync 10.6.

[bobby03]

This issue isn't fixed for me till today :-( I have installed macos catalina but I have this problem since high sierra. Whats can I do? Is there a workaround or can I do something (for e.g.in terminal) to handle this problem?

[Zenju]

This issue isn't fixed for me till today :-( I have installed macos catalina but I have this problem since high sierra. Whats can I do? Is there a workaround or can I do something (for e.g.in terminal) to handle this problem?

What error message do you get?

[bobby03]

Die Dateiattribute von "/Volumes/dokumente/xxx/20191217_Wohnfläche.pdf" können nicht gelesen werden.

Fehlercode 2: No such file or directory [lstat]

[Zenju]

Which FreeFileSync version are you using? Are you able to otherwise access this file, e.g. via command line or Finder?

[Ellul]

Same issue here on MacOS Catalina with FFS 10.20. Some files - but not all - with extended characters throw up lstat error 2.

eg
Cannot read file attributes of "/Volumes/music/F/Funkstörung".
Error Code 2: No such file or directory [lstat]

The files concerned are present and readable in Finder on the mac.

All files in the comparison were originally copied (using FFS 10.20 on mac) from an NTFS external drive to an APFS volume without the same errors (only errors being ffslock file could not be created on the r/o NTFS drive). No errors were encountered on a linux machine comparing the same NTFS drive with a mounted network share. I compared the same folders and drives with GoodSync and it gave similar errors on the same files.

Comparison is also noticeably slower on MacOS - 10mins to traverse approximately 170,000 files as against less than 4 on the older and less powerful linux machine

[bobby03]

I am using the newest version (I think it’s 10.20.) an the newest Mac version. But as I sad this problems exists since high Sierra in every ffs version for some files with characters like ä,ö,ü in the filename.

[bobby03]

Is there any possible solution?

[Zenju]

Die Dateiattribute von "/Volumes/dokumente/xxx/20191217_Wohnfläche.pdf" können nicht gelesen werden.

Fehlercode 2: No such file or directory [lstat]

I bet this file name is in decomposed Unicode form, so this is the following problem: viewtopic.php?t=2480#p18965

[bobby03]

Hey, thanks for your help und your analysis of the problem. But is there any solution or workaround? Because otherwise the program is unusable for me... other programs like sync folders pro can copy these files- but they are not as performant as ffs is und the user interface is not really user friendly...

[Zenju]

In what Unicode form are the file names that are failing?
You can check by looking at the hex representation via terminal:

echo 20191217_Wohnfläche.pdf | od -An -vtx1


(open terminal, cd /Volumes/dokumente/xxx/, enter 201912 and press tab key)

Here's a FFS test version that is converting decomposed into precomposed form when needed. Does it work in your test case?
https://www.mediafire.com/file/7t3810io0di9978/FreeFileSync_10.24_beta_macOS.zip

[bobby03]

I'm sorry, but this beta version doesn't fix that issue. I've used the terminal to read out the specificiations of the composing format. You can see it in the screenshot. Does that help you to fix that issue? Thanks for your help!

[Zenju]

It seems I'm making my life harder than it needs to be. My former self knew a smarter command:

Easy, just go to the directory containing the file on Linux, enter

ls | od -c -t x1


[Zenju]

I can already see, this is indeed the same problem mentioned with Unicode decomposed normal form not understood by macOS when served via Samba.

Are you able to access these files via other means, e.g. via terminal "cat 20191217_Wohnfläche.pdf"?

[bobby03]

No, I cannot access these file in this way.

[Zenju]

No, I cannot access these file in this way.

Neither can I in my test.

IIRC it was possible to access decomposed Unicode forms by converting them to precomposed because this is the variant the macOS Samba implementation is using (despite macOS using decomposed forms in all other areas).

However this doesn't work (anymore?). So currently it looks like there is no way to access these files on macOS.

[cju18]

I'm also facing the same problem. I want to sync to my connected Linux Samba Server on OSX 10.11 and have issues with all files with ä, ü, ö etc.

In the terminal I can see the files with ls but can't access them with cat "Notenblatt mit B und F Schlüssel.pdf" (funny thing: when using autocomplete by pressing tab, it autocompletes the visually same filename, but this time it can access the file)

The 10.24 beta does not improve the problem.

ls | od -c -t x1
0000000    B   a   c   h  \n   B   e   e   t   h   o   v   e   n  \n   B
           42  61  63  68  0a  42  65  65  74  68  6f  76  65  6e  0a  42
0000020    l   u   e   s  \n   C   h   o   p   i   n  \n   N   o   t   e
           6c  75  65  73  0a  43  68  6f  70  69  6e  0a  4e  6f  74  65
0000040    n   b   l   a   t   t       m   i   t       B       u   n   d
           6e  62  6c  61  74  74  20  6d  69  74  20  42  20  75  6e  64
0000060        F       S   c   h   l   u    ̈  **   s   s   e   l   .   p
           20  46  20  53  63  68  6c  75  cc  88  73  73  65  6c  2e  70
0000100    d   f  \n   N   o   t   e   n   b   l   a   t   t   .   p   d
           64  66  0a  4e  6f  74  65  6e  62  6c  61  74  74  2e  70  64
0000120    f  \n   P   o   p  \n   S   c   h   u   b   e   r   t  \n   b
           66  0a  50  6f  70  0a  53  63  68  75  62  65  72  74  0a  62
0000140    e   e   t   h   o   v   e   n   s   _   s   i   l   e   n   c
           65  65  74  68  6f  76  65  6e  73  5f  73  69  6c  65  6e  63
0000160    e   .   p   d   f  \n                                       
           65  2e  70  64  66  0a                                       
0000166


Are there any workarounds? Do you want me to test sth on my OS?

[Zenju]

ls | od -c -t x1
0000060  u   ̈    **
         75  cc  88


Decomposed Unicode.

funny thing: when using autocomplete by pressing tab, it autocompletes the visually same filename, but this time it can access the file

Which Unicode form do you get when you pipe this auto-completed filename to "| od -c -t x1" ?

[cju18]

I get the following output for tab autocomplete (above) and written filename (below):

ls od.png (39.37 KiB) Viewed 4052 times

This is as well interesting: the file with "ä" seems to be invisible - it is only listed with command ls -a.

ls.png (35.75 KiB) Viewed 4052 times

[Zenju]

I get the following output for tab autocomplete (above) and written filename (below):

This is as well interesting: the file with "ä" seems to be invisible - it is only listed with command ls -a.

ls -a only lists the file names without querying for detail information (lstat). ls -l on the other hand tries to access the file metadata and fails. So the behavior is the same as for FreeFileSync.

The only thing I dont understand is your previous comment: "when using autocomplete by pressing tab, it autocompletes the visually same filename, but this time it can access the file".

Is this still the case? If you "cat" the auto-completed file name, it prints the content? The beta above converts to precomposed form when the file is not found. Maybe the form is already returned precomposed in your case (it's decomposed in my tests), and needs to be converted to decomposed...