I have 1 PC running Windows 7, and a Mac where my ext NTFS drives are plugged.
To synchronise, i use FreeFileSync.. let's say at the first pass, all is copied on to the ext drives behind the mac. but when i compare again, some files are shown new when in fact existing on these drives. All of them have a accent on folder or file name.
How can I fix this ?
FreeFileSync not seeing Files and folders with accents on external usb
- Posts: 3
- Joined: 22 Sep 2013
-
- Site Admin
- Posts: 7281
- Joined: 9 Dec 2007
This seems to be the same problem as discussed here where OS X normalizes UTF when storing files which is seen as a file rename operation by all other OS like Windows or Linux:
[404, Invalid URL: https://sourceforge.net/p/freefilesync/bugs/250]
[404, Invalid URL: https://sourceforge.net/p/freefilesync/bugs/250]
- Posts: 3
- Joined: 22 Sep 2013
Hello
Thank you very much for the feedback, I have the exact same problem, using ffs and paragon on a mac-mini version 7.5 (lion), and copying from windows 7 64 bits to ntfs usb attached behind the mac.
The explanation is exact, and I saw in many forums the UTF8 issue being resolved via ffs fix. (BTW, [404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_5.14_Mac_OS_X_64-bit_beta.zip] link is not working).
Well, we are now at version 5.21 and I can confirm the issue still exist.
Another thing, to make this happen, I use SMBup, would this alter some kind of permission to write utf-8 ? or does ffs need some add-on ?
Thank you very much for the feedback, I have the exact same problem, using ffs and paragon on a mac-mini version 7.5 (lion), and copying from windows 7 64 bits to ntfs usb attached behind the mac.
The explanation is exact, and I saw in many forums the UTF8 issue being resolved via ffs fix. (BTW, [404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_5.14_Mac_OS_X_64-bit_beta.zip] link is not working).
Well, we are now at version 5.21 and I can confirm the issue still exist.
Another thing, to make this happen, I use SMBup, would this alter some kind of permission to write utf-8 ? or does ffs need some add-on ?
-
- Site Admin
- Posts: 7281
- Joined: 9 Dec 2007
Did you test with the Windows or the OS X version of FreeFileSync?
I'd expect no problems on OS X since this version decomposes UTF8 into a common form, but there may be a file name mismatch when running FFS on Windows or Linux which presents the file paths as read from the OS without any modification.
I'd expect no problems on OS X since this version decomposes UTF8 into a common form, but there may be a file name mismatch when running FFS on Windows or Linux which presents the file paths as read from the OS without any modification.
- Posts: 3
- Joined: 22 Sep 2013
I tested from windows using FFS.
First pass, FFS copy over Ext HDD hosted by MAC.
Second Pass, FFS wish to add all files (already existing as per first pass).
When it was written on HDD, the filename was changed (é become e'). Therefore as FFS see different filename, it will try to add again...then end in error as filename already exists when trying to write.
First pass, FFS copy over Ext HDD hosted by MAC.
Second Pass, FFS wish to add all files (already existing as per first pass).
When it was written on HDD, the filename was changed (é become e'). Therefore as FFS see different filename, it will try to add again...then end in error as filename already exists when trying to write.
-
- Site Admin
- Posts: 7281
- Joined: 9 Dec 2007
The three variants of FFS on Windows, Linux, OS X implement the platform-specific default behavior (strictly speaking it's file system behavior):
1. Windows/NTFS stores file names as UTF16 without any modification but ignores case-sensitivity
2. Linux stores file names as UTF8 without modification respecting case
3. OS X/HFS stores files as decomposed UTF8 ignoring case
The problem in your case is that the Windows version of FFS does not honor the restrictions of the OS X platform. This is expected and by design. The solution has therefore to be implemented in the software layer that runs on Windows but does not conform to Windows conventions.
In your example the problematic component seems to be the interface that allows you to access OS X files from Windows. Now this component cannot do anything about the fact that HFS changes the UTF8 representation, which is correct for an OS X platform, but since it interfaces with Windows it should remedy this fact and return precomposed UTF8 - the default UTF8 variant on Windows.
1. Windows/NTFS stores file names as UTF16 without any modification but ignores case-sensitivity
2. Linux stores file names as UTF8 without modification respecting case
3. OS X/HFS stores files as decomposed UTF8 ignoring case
The problem in your case is that the Windows version of FFS does not honor the restrictions of the OS X platform. This is expected and by design. The solution has therefore to be implemented in the software layer that runs on Windows but does not conform to Windows conventions.
In your example the problematic component seems to be the interface that allows you to access OS X files from Windows. Now this component cannot do anything about the fact that HFS changes the UTF8 representation, which is correct for an OS X platform, but since it interfaces with Windows it should remedy this fact and return precomposed UTF8 - the default UTF8 variant on Windows.
