ERROR_FILE_EXISTS [CopyFileEx] on Samba share

[Marek-M]

A week ago and a moment ago I made a backup with "FFS 1.14" on the NAS (Samba share) and there were no "CopyFileEx" errors. I don't know what happened but "FFS" fixed itself or one of the Windows updates changed something.

The program said that version 1.15 is now available. Due to the fact that for two weeks I have not been able to get errors in synchronization in version 1.14, I think I can update the application. @Zenju, you don't need to test version 1.14, which works fine?

[john78]

Hello, I have installed version 11.15 beta. I have already mirrored three directories and so far no Copyfile errors have been reported.
Yours sincerely,

[dskouras]

In my case I've had this problem for while and assumed it was an issue with my setup. I just now realized there's a problem with the Application.

I am using 11.15 donation version and have the issue on all my syncs from NTFS drives to my synology NAS.

I've tried running the software under windows 10 and Debian 11 and I get the problem in both cases (actually in Debian I get a few more errors that I can't be bothered to debug, so I just click ignore.

Is there any advice on how to fix this?I really need the sync processes to run...
Happy to send any logs that might be useful

[Zenju]

In my case I've had this problem for while and assumed it was an issue with my setup.

Is it reproducible? Are you able to simplify your sync to a single file that exhibits the ERROR_FILE_EXISTS error?

I just now realized there's a problem with the Application.

Well the problem lies not with FFS, but the software could implement a workaround to what appears to be a bug in Microsoft's CopyFileEx().

I've tried running the software under windows 10 and Debian 11

Interesting, whatever errors you're seing in Debian, it's almost certainly something else than what is discussed in this thread, which is a Windows-specific issue.

[dskouras]

Hi and thank you for replying!

In my case I've had this problem for while and assumed it was an issue with my setup.

Is it reproducible? Are you able to simplify your sync to a single file that exhibits the ERROR_FILE_EXISTS error?

My sync's all generally sync mirror the contents of folders and drives on my desktop to my synology NAS.

I tested several sync pairs, from a simple one with one file to more complex ones with hundreds of files including documents, photos and software. All ran fine with no (significant errors)

However two particular sync pairs fail with this error - one syncing my home videos and another with several hundred archives (zip/rar etc). There I got several hundred "ERROR_FILE_EXISTS: The file exists. [CopyFileEx]" instances - basically one for every file to be copied, so no files were copied.

I have no idea why these two fail, but one thing they have in common is the size of the files - the smallest one is about 50MB and the largest a few gigabytes.

I tried creating various combinations of sync settings for these files but all failed.

I also got a new error on one of them:
"Cannot open directory "F:\Recovery".
ERROR_ACCESS_DENIED: Access is denied. [DirReaderPlus]"
Its confusing because there is no file or folder called Recovery on this drive, not even a hidden one.

I hope this helps a bit, as I said happy to provide logs etc if useful,

I just now realized there's a problem with the Application.

Well the problem lies not with FFS, but the software could implement a workaround to what appears to be a bug in Microsoft's CopyFileEx().

Understood, thank you for clarifying.

I've tried running the software under windows 10 and Debian 11

Interesting, whatever errors you're seing in Debian, it's almost certainly something else than what is discussed in this thread, which is a Windows-specific issue.

I'm currently on windows 10, but I will reboot to Debian (it's a dual boot system), run it again and report back. I should mention to be precise that I'm running Debian testing, so in fact not the most solid environment. Not sure if that might play a part.

[dskouras]

OK, I can confirm that the issue does not occur in Debian. The error I got was another one about another one about not having access to sync.ffs_tmp

Syncs work as expected in Debian.

[Zenju]

There I got several hundred "ERROR_FILE_EXISTS: The file exists. [CopyFileEx]" instances

Sounds good (as a test case). But first simplify the scenario by setting an include file filter so that only a single file that fails copying with ERROR_FILE_EXISTS will be synced.
I'll also need a Process Monitor log to verify that FFS's workaround is in fact doing the right thing.

So the procedure then is:

1. Start Process Monitor and begin logging: https://freefilesync.org/faq.php#trace
2. Run the sync (with a single failing file) by using this FFS beta: https://www.mediafire.com/file/nrwos2l1lk7byf8/FreeFileSync_11.16_%255BBeta1%255D_Windows_Setup.exe
3. Hopefully this time the sync worked, then send me the pml file via email.

(4.) Retry the steps above using beta version 2, which uses a slightly different workaround: https://www.mediafire.com/file/1kbuof4gnn5vqsl/FreeFileSync_11.16_%255BBeta2%255D_Windows_Setup.exe

"Cannot open directory "F:\Recovery".
ERROR_ACCESS_DENIED: Access is denied. [DirReaderPlus]"
Its confusing because there is no file or folder called Recovery on this drive, not even a hidden one.

This is an unrelated error. "F:\Recovery" does in fact exist and is internal to Windows. It's not only marked "hidden", but also "system".

[Chribaa]

my severe issues (see my post from Jul 24, 2021) have been successfully resolved with the first beta, that Zenju had posted on Dec. 27.
@Zenju: thanks so much for this. Now FFS becomes a useful tool for me!

[Zenju]

my severe issues (see my post from Jul 24, 2021) have been successfully resolved with the first beta, that Zenju had posted on Dec. 27.
@Zenju: thanks so much for this. Now FFS becomes a useful tool for me!

For the beta to become official I still need the Process Monitor trace for verification, and a second trace for beta version 2.

[Chribaa]

@Zenju, as per my mail it is difficult to provide a full PML due to the laptop being corporate. If you can point out, what specifically you need, I could send screenshots of these parts.

[donauinsel]

In my case its a special character in files stored in user directory.

[Zenju]

In my case its a special character in files stored in user directory.

I suspect there is something else going on. FreeFileSync supports Unicode fully, including emojis.

[Plerry]

See viewtopic.php?t=9501&p=34560

[kamkie]

beta insaller has expired

[schakie]

Unfortunetely looks like there's still no solution..

I just switched to a fresh Win10 installation (build 19044.2006) with FFS V11.25 and now I'm getting the same error:
ERROR_FILE_EXISTS: Die Datei ist vorhanden. [CopyFileEx]

Process monitor also shows the mentioned lines:

13:59:47,4011888    FreeFileSync_x64.exe    13908    CreateFile   
\\dose2\Daten\User\x\Backup\Favoriten\bookmark~4525.ffs_tmp   
EAS NOT SUPPORTED   
Desired Access: Generic Read/Write, Delete, Write DAC, Disposition: Create, Options: Sequential Access, Non-Directory File, Attributes: A, ShareMode: None, AllocationSize: 14.153

13:59:47,4153934    FreeFileSync_x64.exe    13908    CreateFile   
\\dose2\Daten\User\x\Backup\Favoriten\bookmark~4525.ffs_tmp   
NAME COLLISION   
Desired Access: Generic Write, Read Data/List Directory, Read Attributes, Delete, Write DAC, Disposition: Create, Options: Sequential Access, Non-Directory File, Attributes: A, ShareMode: None, AllocationSize: 14.153

13:59:47,4242228    FreeFileSync_x64.exe    13908    CreateFile   
\\dose2\Daten\User\x\Backup\Favoriten\bookmark~4525.ffs_tmp   
NAME COLLISION   
Desired Access: Generic Write, Read Attributes, Delete, Write DAC, Disposition: Create, Options: Sequential Access, Non-Directory File, Attributes: A, ShareMode: None, AllocationSize: 14.153

13:59:47,4474411    FreeFileSync_x64.exe    13908    CreateFile   
\\dose2\Daten\User\x\Backup\Favoriten\bookmark~4525.ffs_tmp   
NAME NOT FOUND   
Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a


Get-SmbConnection shows I'm using SMB V2.1 for connection to my QNAP NAS

I will be happy to assist with testing betas etc..

[Zenju]

EAS NOT SUPPORTED

That's definitively the SMB bug that FFS could try to workaround. I'll prepare new beta versions for testing.

[Zenju]

Here are the two betas. When testing please also create a PML file so that I can verify the beta does in fact fix the issue: viewtopic.php?t=7898&start=30#p32404

Beta 1: https://www.mediafire.com/file/0lu1kov15b4rblm/FreeFileSync_11.26_%255BBeta1%255D_Windows_Setup.exe
Beta 2: https://www.mediafire.com/file/4btthv4ocdrxa3d/FreeFileSync_11.26_%255BBeta2%255D_Windows_Setup.exe

[schakie]

both betas are working, showing no error, copying the intended file and leaving no .ffs_tmp file behind.

Also when I reinstalled 11.25 Release version the error came back (as expected).

I sent you the PML files...

[Zenju]

both betas are working, showing no error, copying the intended file and leaving no .ffs_tmp file behind.

Also when I reinstalled 11.25 Release version the error came back (as expected).

I sent you the PML files...

Thank you very much! The workaround is doing as expected according to the PML files. The fix will be officially available in the next version FreeFileSync 11.26.

[schakie]

Cool, thank you!
In the meantime I'll use the beta...

[edechamps]

Hi,

I am not a FFS user, however I stumbled upon this thread while trying to understand why I was getting empty files being created and weird "The destination already has a file named X" errors from Explorer while attempting to copy files to a Samba share.

This is indeed a Samba bug, and I took the liberty of filing it against them: https://bugzilla.samba.org/show_bug.cgi?id=15563

The bug happens when Samba is configured with `ea support` enabled (note this is the case by default starting from Samba 4.9) and one attempts to create a file with extended attributes and the underlying filesystem does not support user xattrs.

Probably the cleanest solution is to ensure Samba is serving from a filesystem with user xattrs support.

Otherwise, a workaround is to explicitly set `ea support` to `no` in Samba smb.conf. This will disable extended attributes, but those are rarely useful, and this makes no difference if the underlying filesystem doesn't support them anyway.

[pkiff]

Interesting discovery @edechamps. Thanks for your work on this and for dropping a note in here. I may see if I can fiddle with my smb conf settings on my NAS - though I haven't encountered the errors in FFS for a while now.