Constantly get these non-critical errors each and every time

[Milkman]

Each time Syncback does a backup I get the following non-critical errors for each and every file that it copies (which it does successfully BTW):

failed to change attributes: The process cannot access the file because it is being used by another process.

The files are not in use. Any idea what I am doing wrong???

[Dave Wilkins]

Something on your device (is it a NAS, by any chance?) is saying they are when Pro tries to make sure the attributes match Source (by force-setting them). If they are being copied OK otherwise, you can ignore them.

[Milkman]

Something on your device (is it a NAS, by any chance?) is saying they are when Pro tries to make sure the attributes match Source (by force-setting them). If they are being copied OK otherwise, you can ignore them.

It is a NAS drive.

Is there something I can do to make the errors go away?? A change I can make or something?? It does copy successfully, but I just don't like errors.

[Dave Wilkins]

Try checking for any updates to the NAS firmware (it's likely not releasing the write lock in a timely manner after copying is complete). Or, change the NAS Or, put up with it.

[Milkman]

Unfortunately I am on the latest firmware.

Is there something I can change in SB to tell it to stop trying to change the attribute?

[Dave Wilkins]

Not as far as I know (or I would have said already), but I'll double-check with the developer.

[Dave Wilkins]

The functionality is as follows

Pro is trying to set the attributes (it's usually quicker to just set them anyway, and not check beforehand). If it fails, it will get the existing attributes (of the copy) to see if they match the Source anyway (if so, it doesn't log an error - no harm, no foul, etc)

So it seems your NAS

a) doesn't store them properly by default in the first place
b) it won't let them be force-set either

so the non-critical error is logged. There's no way to turn it off, except get a better NAS, sorry - or lobby for better firmware, and wait.

[jsmply]

If that error is not of concern to him/her (which they seem to be expressing by saying can it be turned off), is there anyway to not log that particular error that might give it the appearance of a clean run?

[Dave Wilkins]

No (I would have said...). The developer's philosophy is that due to hardware (or firmware) errors, the copy is not the same as the original (different attributes), so you should be told. Bear in mind that it doesn't set the overall Result as a Failure, so you'll only see them if you look for them.

[jsmply]

Makes perfect sense.