"Could not read attributes of file: Temporary access error: ERROR_FILE_NOT_FOUND"

[kRel]

Hi...

For some time now, syncs have been crashing frequently and more than once with pop-up alerts like this:

"Could not read attributes of file: 'E:\OTHER\RecycleBin~68d0.ffs_temp\LINKS'.
Temporary access error: ERROR_FILE_NOT_FOUND: The specified file cannot be found. [GetFileAttributes]

--
The names of the files and directories change from time to time and the error occurs even if I start FFS with elevated privileges, but this is normal, I think...

If I click on "Ignore" the synchronization proceeds up to any subsequent similar errors and the error in subsequent synchronizations is no longer repeated.

So there is a partial way to bypass the error, but the error is repeated every time FFS is started after 2 or more days and FFS remains blocked until manual intervention.

Apart from the particularly curious names of the files, files that seem to be generated by FFS, that the names and directories change from time to time, how to solve this problem since a filter does not seem to be applicable?

FFS 12.1 64Bit 21-02-2023 donation

Cheers

[xCSxXenon]

You should exclude any recycle bin folders from your syncs

[kRel]

You should exclude any recycle bin folders from your syncs

The recycled.bin had already been excluded for two years.

By installing the "Donate" version two months ago the old settings migrated from free to Donate, in fact the filters for recycle.bin remained.

Please - if you want - look carefully at the address of the error in OP: it is not the standard address of recycle.bin whose syntax should be e.g. D:\$RECYCLE.BIN\**\**
but it is. 'E:\OTHER\RecycleBin~68d0.ffs_temp\LINKS'.
by prefixing "OTHER", it seems an anomaly.

Until two months ago I NEVER had this error, and I haven't changed a thing!

Now - to the absolute path \$RECYCLE.BIN\*\ I added three paths that I know are wrong: C:\$RECYCLE.BIN\*\ - D:\$RECYCLE.BIN\*\ - E:\$RECYCLE. BIN\*\

Maybe if you have a suggestion. . .

[Plerry]

Your Exclude Filter entries
C:\$RECYCLE.BIN\*\ - D:\$RECYCLE.BIN\*\ - E:\$RECYCLE. BIN\*\
are wrong, because they specify an absolute path, while the Include and Exclude Filter need to contain a path relative to the left and right base location (although Zenju added some smart adaptations to partially deal with that).
Instead, try an Exclude Filter line
*RecycleBin*
That should exclude anything that has RecycleBin anywhere in the file- or folder-name.
Character case is not relevant here.

[kRel]

Thanks, now I have no more errors. Removed absolute paths, put relative references to Recycle in "local" filters and put *RecycleBin* in the general filter

[Zenju]

The <base folder>\RecycleBin~68d0.ffs_temp folders are temporarily created by FFS to gather all to be recycled files, and move them to the drive's recycle bin in one go. They're cleaned up automatically after sync (or so they should).
If another FFS instance sees them, it means something went wrong with the clean up. But it's not a permanent problem, because this other FFS run takes over and also tries to move them to the recycle bin (but without creating yet another ffs_temp folder in the process)
Excluding these folders via filter is not a good idea, because this means these folders are never cleaned up and will clutter your backup drive.

[kRel]

The <base folder>\RecycleBin~68d0.ffs_temp folders are temporarily created by FFS to gather all to be recycled files, and move them to the drive's recycle bin in one go. They're cleaned up automatically after sync (or so they should).
If another FFS instance sees them, it means something went wrong with the clean up. But it's not a permanent problem, because this other FFS run takes over and also tries to move them to the recycle bin (but without creating yet another ffs_temp folder in the process)
Excluding these folders via filter is not a good idea, because this means these folders are never cleaned up and will clutter your backup drive.

Also for this same problem I started by mistake - having forgotten my first question - a second request. I'm sorry. I would like to continue here if possible please.

On my second request @Plerry replied:
Zenju explained the use of the Recyclebin...ffs_tmp folder
"Most likely cause for your problem seems to be multiple instances of FFS running at the same time or early termination of an FFS instance."
referring me to your reply here.

For my part I understood what you wrote, in fact the synchronizations carried out within a short time the error does not repeat itself.
(I will delete the filters as recommendations).

However, after 4/5 days the same error sometimes occurred again frequently, without me touching FFS in any way.
Indeed, the configuration of FFS has always been the same for some years. Only change, I switched from the free version to the donated version, but continuing to use the configuration I used with the free version, used hundreds of times without errors.

I confirm that I have never started multiple instances of FFS running at the same time, nor have I ever terminated the FFS instance prematurely. After all, I would have no reason to carry out these two operations, and it would also be stupid to terminate a synchronization in advance. . .
------------

edit of March 21st:

Even today I have the same errors ...

I didn't start several FFS instances at the same time, I didn't close the FFS instance prematurely.

How can I fix?

[xCSxXenon]

I wonder if the drive(s) is failing

[kRel]

I wonder if the drive(s) is failing

It could also be... But only with FFS?
I have no warnings about disk problems, SMART reports nothing, scandisk/chkdsk reports no errors.

[Zenju]

Most likely a buffering issue with the "E:\" network share. Are you using multiple synchronization threads?
Do you see these "RecycleBin~68d0.ffs_tmp" folders also when you navigate there using Windows Explorer?
It's unclear to me whether these ffs_tmp folders are remnants from a previous sync, or not.

[kRel]

Most likely a buffering issue with the "E:\" network share. Are you using multiple synchronization threads?
Do you see these "RecycleBin~68d0.ffs_tmp" folders also when you navigate there using Windows Explorer?
It's unclear to me whether these ffs_tmp folders are remnants from a previous sync, or not.

thanks
Most likely a buffering issue with the "E:\" network share.
You call her (or you see it) "network share" - but it is only a third disk inside the PC
[1st: C:\systemdisk
2nd: D:\ data disk (and backup some user files on C:\User\Myuser to D:\UserBackup via FFS)
3rd E:\ backup disk (mirroring via FFS some folders from disk D:\ to disk E:\ and backup of some user files on D:\User\Myuser to E:\UserBackup via FFS )]

you using multiple synchronization threads?
No. I'm currently using only one sync tread. At least I think so...

Do you see these "RecycleBin~68d0.ffs_tmp" folders also when you navigate there using Windows Explorer?
No. After receiving the error pop-up, searching for timo files: "RecycleBin~123abc.ffs_tmp" doesn't find anything. Not even by enabling the display of hidden files nor by enabling the display of system files.

It's unclear to me whether these ffs_tmp folders are remnants from a previous sync, or not.
I don't know if my answer answers your question: but as I answered someone further up, if I launch a second - identical - synchronization immediately after the error, the files like "RecycleBin~123abc.ffs_tmp" are no longer reported.

cheers

if you want, look at the images of the errors at the links in the exact sequence in which they occur:
1. https://www.imagebam.com/view/MEJP3OY
2. https://www.imagebam.com/view/MEJP3QL
3. https://www.imagebam.com/view/MEJP3U9
4. https://www.imagebam.com/view/MEJP3VE
5. https://www.imagebam.com/view/MEJP3VL
6. https://www.imagebam.com/view/MEJP3W9
7. https://www.imagebam.com/view/MEJP3WN
8. https://www.imagebam.com/view/MEJP3WY
9. https://www.imagebam.com/view/MEJP3X3

[kRel]

Today:

[Salvatore Besso]

hello,

just joined the forum. I hit this error as well, but in my case the recycle bin has nothing to do with my problem. Some additional information before explaining:

- This problem happens with not only one job, but with several.
- All my jobs use UNC paths for the destinations and for the previous copies of the files and folders
- All UNC folders are now on a Synology NAS. Previously on a QNAP NAS with the same problem.
- All my jobs use 8 threads for all paths.
- I had this problem when I passed from the free to the Donation edition, starting to use multiple threads.
- I have not tried to use only one thread yet.
- I've never had this problem in the past with both NAS.

This is a screenshot of the error. Please notice that the error code says ERROR_FILE_NOT_FOUND, but in reality it is a folder, not a file (maybe something to fix?):

FreeFileSync 1.jpg (212.03 KiB) Viewed 2048 times

As you can see in the image, it is a folder that already exists, created by FreeFileSync itself, and that already contains something.

The folder indicated in the above image is one of the subfolders of the root folder where FreeFileSync has been instructed to save previous copies of the synchronized files, as in the following image:

FreeFileSync 2.jpg (73.79 KiB) Viewed 2048 times

Well, if I click the "Retry" button two things may happen:

1) The error reiterates again for "n" times (where "n", at least until now, may vary from 1 to 3) with other subfolders that already exist like the first, but finally it goes away and synchronization continues well until the end. Here is a reiteration of the error. Please, notice the same error code for a FILE when it's a folder again:

FreeFileSync 3.jpg (224.02 KiB) Viewed 2048 times

2) The synchronization continues well until the end after the first "Retry"

What can I do to resolve this problem and to continue to use multiple threads?

Thank you
Salvatore

[xCSxXenon]

That sounds more like the NAS is reporting the folder as a file incorrectly. I would bet that syncing the same source to a local local would work fine every time

[Salvatore Besso]

That sounds more like the NAS is reporting the folder as a file incorrectly. I would bet that syncing the same source to a local local would work fine every time

it sounds strange that a NAS could erroneously report a folder as a file. But apart this, as I wrote, I have always used a NAS as destination, and the main problem (error) never happened before.

Salvatore

[kRel]

Back to discussion also because to @Salvatore Besso these errors happen with the "Donate" version and - as happens to Salvatore - I too have to click 2 or more times on "Ignore" to complete the synchronization.

With the Free Portable version

FreeFileSync_11.28_[Donation_Edition]_Windows_Portable

downloaded a week ago for specific testing purpose and placed on the Desktop of Windows 10 Pro v22h2 64 bit - with the same - identical ".ffs_gui" or ".ffs_batch" configuration files used in the Donate version
the problem never happened!.

After all, this error never occurred until I used the free version. The error only started happening with the Donate version.

I repeat and remember that the error occurs between two HDDs of the same PC

I think that the difference in behavior between the Free version and the Donate version should be considered....

Greetings.

[Salvatore Besso]

I think the detail is important and that this singularity needs to be considered.

hello, thank you for the support :-)

I also want to emphasize that there is no recycle bin involved in my case.
I also want to emphasize that not all the jobs suffer of this problem, but all the jobs have the same NAS as destination.

Thank you to all who can help.

Salvatore

[Salvatore Besso]

Back to discussion also because to @Salvatore Besso these errors happen with the "Donate" version and - as happens to Salvatore - I too have to click 2 or more times on "Ignore" to complete the synchronization.

With the Free Portable version

FreeFileSync_11.28_[Donation_Edition]_Windows_Portable

downloaded a week ago for specific testing purpose and placed on the Desktop of Windows 10 Pro v22h2 64 bit - with the same - identical ".ffs_gui" or ".ffs_batch" configuration files used in the Donate version
the problem never happened!.

After all, this error never occurred until I used the free version. The error only started happening with the Donate version.

I repeat and remember that the error occurs between two HDDs of the same PC

I think that the difference in behavior between the Free version and the Donate version should be considered....

Greetings.

I am able now to confirm your behaviour. I have uninstalled the donation edition and I have downloaded and then installed the free edition. I have loaded the same jobs and I have executed the eight RTS jobs. Zero errors until now.

I have an hypothesis: the free edition ignores whatsoever threads one has setup in the job and runs with only one thread. I can see 8 threads in the job, but they are grayed out.

So, in my humble opinion, I would look at the thread part of the code.

Salvatore

[xCSxXenon]

To clarify,

With the Free Portable version

There is no portable version for the free edition.

After all, this error never occurred until I used the free version. The error only started happening with the Donate version.

This probably means 'this error never occurred while using the free version.

[Zenju]

@Salvatore Besso: I'm pretty sure this is a (file system) race condition when multiple threads are trying to create the versioning folders => TODO

@kRel: I suspect it's a similar issue when multiple threads are creating the temp directories for recycling, but:

you using multiple synchronization threads?
No. I'm currently using only one sync tread. At least I think so...

Are you sure about that? What values have you set for "parallel file operations" (see comparison settings F6)?

[Salvatore Besso]

@Salvatore Besso: I'm pretty sure this is a (file system) race condition when multiple threads are trying to create the versioning folders => TODO

@kRel: I suspect it's a similar issue when multiple threads are creating the temp directories for recycling, but:

What values have you set for "parallel file operations" (see comparison settings F6)?

just to add my two cents, I have set 8 in "parallel file operations" for all folders in all jobs.

Salvatore

[Zenju]

Issues should be fixed, please try again in FFS 12.2 (release planned for today or tomorrow).

[kRel]

@kRel: I suspect it's a similar issue when multiple threads are creating the temp directories for recycling, but:

you using multiple synchronization threads?
No. I'm currently using only one sync tread. At least I think so...

Are you sure about that? What values have you set for "parallel file operations" (see comparison settings F6)?

Hi thanks,

You are right. I was only able to check now.

Both in the "Portable" version and in the installed version are set 4 treads.

However, the installed version continues to give that warning today again, while the Portable version (copied to the desktop) starts and finishes the synchronization without errors - despite having set 4 parallel operations like the installed version.

Remember that both versions use the same .ffs_batch/.ffs_gui file

What to do ?

[Zenju]

Both in the "Portable" version and in the installed version are set 4 treads.

Great, the next version should fix this, too.

However, the installed version continues to give that warning today again, while the Portable version (copied to the desktop) starts and finishes the synchronization without errors - despite having set 4 parallel operations like the installed version.

That's just a coincidence. Race-conditions are nondeterministic by nature.

[Salvatore Besso]

Both in the "Portable" version and in the installed version are set 4 treads.

Great, the next version should fix this, too.

However, the installed version continues to give that warning today again, while the Portable version (copied to the desktop) starts and finishes the synchronization without errors - despite having set 4 parallel operations like the installed version.

That's just a coincidence. Race-conditions are nondeterministic by nature.

Zenju,

on another computer I have still the Donation edition installed; I have reduced all threads in all jobs to only one. The errors are gone.

Can it be of help?

Salvatore

[Salvatore Besso]

despite having reduced to one all threads in all jobs, I've just got this error with the free edition:

Screenshot - 02_04_2023 , 23_43_50.jpg (18.44 KiB) Viewed 1890 times

Clicking "Retry" made the job to finish normally.

Salvatore

[kRel]

To clarify,

With the Free Portable version

There is no portable version for the free edition.

After all, this error never occurred until I used the free version. The error only started happening with the Donate version.

This probably means 'this error never occurred while using the free version.

With v12.2 - FreeFileSync 12.2 Windows, updated directly in the app, (installed version, that gave errors) today I have not received any errors with 4 operations in parallel.

[Salvatore Besso]

again with version 12.1:

Screenshot - 05_04_2023 , 10_09_33.jpg (18.41 KiB) Viewed 1854 times

Again, clicking "Retry" makes the job to complete successfully.

Now I will install 12.2 Donation Edition and see...

Salvatore

[kRel]

I confirm: problem solved with new version:

Latest Changes
FreeFileSync 12.2
Fixed temporary access error when creating multiple folders in parallel
Log failure to copy folder attributes as warning only

[Salvatore Besso]

hello,

I have returned to the donation edition since yesterday morning and from that time I haven't had any error. I have made a fine tuning on the number of threads used by the eight jobs, setting them to a reasonable number for what that particular job must do. Useless to set eight threads for a job that has to sync a single file :-). But I have set four threads in the jobs that have a medium number of files to sync and eight in those jobs that have massive quantities of files to sync.

I take this opportunity to ask if FFS has a limit in the number of threads that one can set in a job.

So all is well on this side, but continues in the other thread that I have created for the sluggish behaviour of the computer when the eight jobs are running in the background using RTS (thread name: RealTimeSync seems to slow down the computer), but that thread seems to be dead. I transfer there hoping in a solution for that problem as well.

Thank you.
Salvatore