Why does backup of one applications files always occur when there is no change?

[Bordonbert]

I perform a simple nightly backup set up in Windows Task Scheduler of the whole of MyDocuments. FFS does this perfectly with one exception. I am an electronics engineer and use LTSpice circuit simulation software. This has a huge library of tens of thousands of modelled components in many thousands of files. Occasionally a few of these will be updated but generally there is no activity for any of these files. Every night the whole huge library are copied across during the backup. They are the only ones behaving like this.

There is even a block of files which, immediately after a successful backup, are found again with "Compare" and will be backed up again. And again. And again!

Why are these files not being checked for change and ignored when they are the same as the last backup?

[xCSxXenon]

FFS will give you the reason it wants to sync those files. What reason does it give?

[Bordonbert]

When I do a Compare and it lists the files it says "Left side is newer" but they have just been backed up minutes before. They show dates like: <- 20/03/21; -> 10/12/20. If the previous backup from minutes before was performed fully surely these should now show the same date.

[xCSxXenon]

No errors in the log after syncing?

[Bordonbert]

No none. I'm going through the process again but this time something occurred to me. I am backing up to a location on a network drive which is mapped to a drive in the PC. I had the drive letter as the target for the backup. I asked it do the compare with the full network address and it came up with a completely different display of the files. It found an absolute shed load more which it said were different and showed a much more structured list of their relative locations. It then went ahead with a much bigger Sync which it is working through now.

[xCSxXenon]

Ah, I wonder if the timestamps weren't transferring properly

[Bordonbert]

Yes, that seems to have got it. Pretty weird issue I think. It doesn't seem to like the idea of working to a folder on a network drive mapped as a drive on the base machine. Maybe it just got confused for a while.
It's done the update for a lot of files there this time. Now a new Compare finds nothing different which is what it should find.

So now I know, use the full network address in future. All is happy in my little world again. ThanksxCSxXenon.

[xCSxXenon]

Glad it's working! I wonder if it is just a different protocol that gets used and one doesn't pass that info across.

[Bordonbert]

Just a quick update as there is now more info on this.

Nope, the fix didn't stick. A couple of hours later I was back where I started. Frustrating! So I did a bit more digging around the Synology area and guess what I found? The underlying problem to this has been a known issue in their DSM OS for over 5 years and has been discussed at length on their user forum! The problem is actually acknowledged as Synology's and it isn't just FFS or LTspice related. It appears in many areas where files' timestamps seem to revert back to a previous one. That is so disruptive to usage of a NAS drive you would have thought they would have fixed it by now.

There you go, now we know. I'm still hoping for a solution but it looks like it isn't going to come. Anyone thinking of a Synology drive for their backups using FFS should perhaps look into it.

[xCSxXenon]

That was my next guess actually. I have seen others on here with the same problems caused by the NAS. For what it's worth, building your own NAS built on even Windows or something more purpose driven can be a lot better. You get control over how things are configured, the tradeoff of course being the knowledge required to use it. You may know this, but just some general info for anyone stopping by.