Issues with open ._ files on mac syncing to network share

Get help for specific problems
Posts: 3
Joined: 6 Mar 2019

suthers

Hi All,
This is my senario:
FreeFileSync donation edition running on Mac OSX El Capitan
Syncing external USB key (formatted NTFS) to network NAS share (NAS running Linux Debian OS) over AFP network protocol.
After first sync, for several file types there are duplicate files present, with a ._ prefix. So document.doc will have ._document.doc beside it.
I understand these files are created by OXS to store the attributes fork of the file data on non-HFS file systems. That's all OK. My problem comes when I try to the the second or subsequent syncs.
FreeFileSync throws an error for many of the ._ files when trying to update them. Initially it was an inability to rename the freefilesync temp file to the correct filename. Going into the preferences menu and using direct copy eliminated this error, but created a new one - an inability to update the ._ file because it is 'open'. Presumably this was why the temp file rename operation failed too - the previous destination file couldn't be deleted because it was open.
I don't want to stop syncing the ._ files as we use the adobe suite and actually need the data stored in them.
Is anyone aware of how to get these ._ files into a 'closed' state so the sync can work as intended? I have tried shutting down all the open programs, but that doesn't seem to help. Even unmounting and remounting the network share doesn't fix the problem.
Ideas?
Thanks
Bill
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

https://en.wikipedia.org/wiki/AppleSingle_and_AppleDouble_formats
Sounds as if these files should be excluded from sync. FFS already has an exclude filter on macOS */._.*. I'm just wondering if this is a typo and should be */._* instead.
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

Just changed the default macOS exclude filter to "*/._*". Regarding your "closed state", your target file system needs to support extended attributes, like HFS does.
Posts: 3
Joined: 6 Mar 2019

suthers

Oh I *really* think that excluding the ._ files by default is a bad idea. Unless the user knows for sure they don't need the metadata in the ._ file they will think they have backed up their files, only to find out when opening them in future that properties like author, comments etc are all blank.
Posts: 3
Joined: 6 Mar 2019

suthers

There are also ._. files in the mac file system. I haven't researched them yet, but they may have different function
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

There are also ._. files in the mac file system. I haven't researched them yet, but they may have different function suthers, 07 Mar 2019, 23:58
Really? Aren't these just AppleDouble files for file names starting with a "."? The reason FFS had this filter previously was because of "._.Trash".

What FFS needs is an option for whether AppleDouble files should be created on non-HFS or not. Currently FFS opts-in to not create them, but in your case you'd want to enable it. In any case it would be the system that is creating/copying these files, not FFS, so excluding them from sync would still be correct, to avoid interference.