Unable to syncronize files because of timestamp

Get help for specific problems
Posts: 6
Joined: 5 Nov 2010

rizik29

Hy,
I'm using FreeFileSync for a long time, and I love it. But recently I've encountered a problem. Very large number of files on destination drive changed timestamp and mirroring of source drive through FreeFileSync didn't function, every time I've started FreeFileSync mirroring the same files were reported as unsynchronized. I've checked this, and found out that only way to copy timestamp was through Robocopy (Microsoft program), after that I've run RoboMirror (Robocopy GUI) and synchronization was successful. All this was done on Windows 8.1 with latest updates.
I would like to ask if FreeFileSync can synchronize (copy) timestamp of files, because not even "Copy NTFS permissions" (in Options) didn't help? I hope this situation will not happen again, but just in case...
User avatar
Site Admin
Posts: 7170
Joined: 9 Dec 2007

Zenju

Yes, FreeFileSync copies time stamps since it's probably the most important metadatum for synchronization.

> Copy NTFS permissions

This is unrelated and should be left at its default (=off), unless there is a reason to turn it on.
Posts: 6
Joined: 5 Nov 2010

rizik29

With or without "Copy NTFS permissions" this problem remains. Whenever I update some software on PC FreeFileSync is unable to sync timestamps. Microsoft's RoboCopy does that without problem. Maybe something changed in Windows 8.1 with latest updates, or there is some explanation why these two programs behave so differently?
User avatar
Site Admin
Posts: 7170
Joined: 9 Dec 2007

Zenju

FreeFileSync consistently checks for errors when setting the time stamp. But it's sometimes possible that no error is shown and still file times are not updated:

1. This behavior can be caused by a hardware problem
2. faulty drivers for network, USB 3.0 port, etc.
3. It's also possible that some anti virus software is messing with the files after copy! For example the most recent release of Comodo Anti Virus tries to sneak-in hidden alternate data streams to newly copied files. The end result is that the time stamp is updated once again, but with the current time.
Posts: 6
Joined: 5 Nov 2010

rizik29

It is problem related to Comodo 8, no problem with Comodo 7. And it appears with any type of Comodo installation (I have only Firewall without Anti Virus).
Other programs (like Total Commander) behave same way like FreeFileSync. Microsoft's RoboCopy is not affected by this.
I wrote this cause it may help some other FreeFileSync user if he encounters this problem.
Now I have to see whether to remove Comodo 8 and install Comodo 7, or use RoboCopy for mirroring exe's and dll's until this problem is solved, this second solution is worse for me since Robocopy is nowhere near to possibilities of FreeFileSync.
Posts: 1
Joined: 7 Jan 2005

atomiktd

Thank you Risky73 for pinning it down.

I run Win 7 and in my case it happens only to .js files and vanishes when I switch Comodo's antivirus off.

It is weird because Comodo's antivirus doesn't affect standard Windows copying (via panels). And more, after I successfully copy any .js file using Windows standard method, any following copying (FFS or Total Commander) work perfectly for that particular file.

I still havn't got any solution though.
Posts: 1
Joined: 9 Feb 2015

dikig

I just did some initial testing with your excellent tool and unfortunatly I'm suffering from the same problem my collegues above do. After having synchronized about 30000 files and then redo the sync there are always a number of files left, where the size is equal but the timestamp is wrong on the sync destination and therefore FFS wants to re-sync these files (e.g. 400 to 1400). Although I know that the preceeding sync was correct, this is an undesirable behavior, as many files are re-synced, which already are in sync!

My application is to sync the files of my laptop (XP) to a desktop (W7) via LAN.

I know that this is not a bug of FFS but probably a bug in Windows (Win7 Home). I do not have Comodo running and saw the same behavior with GoodSync, which I actually wanted to replace with FFS. The problem was independent of my virus scanner.
Using GoodSync I have an option to set the timestamps separately and this works well, however, the handling is a nightmare. I do not want to first sync the files and then sync the timestamps separately.

A quick and dirty solution were to allow disabling timestamp testing and only sync based on file size. Of course I'd prefer to find a final solution.

By the way, the problem does not show up when syncing to a locally connected USB-disk or an USB-disk connected to my remote desktop PC!

Any great idea?

Many thanks!
Posts: 1
Joined: 21 Feb 2015

ovono

I like your product overall but am having a similar issue. When moving files around from old back-ups or computer sometimes the last modified date information is changed. So when comparing two folders it will not sync. This is of course what it should do in order to keep track of versions. However, right now I am just trying to organize 1000's of files across 4 different locations. Is there a way to have it ignore the modification date?

thanks
User avatar
Site Admin
Posts: 7170
Joined: 9 Dec 2007

Zenju

It is problem related to Comodo 8, no problem with Comodo 7. And it appears with any type of Comodo installation (I have only Firewall without Anti Virus).
Other programs (like Total Commander) behave same way like FreeFileSync. Microsoft's RoboCopy is not affected by this.
I wrote this cause it may help some other FreeFileSync user if he encounters this problem.
Now I have to see whether to remove Comodo 8 and install Comodo 7, or use RoboCopy for mirroring exe's and dll's until this problem is solved, this second solution is worse for me since Robocopy is nowhere near to possibilities of FreeFileSync.rizik29
For the record, here's the discussion on the Comodo forums concerning this bug(?):
http://forums.comodo.com/install-setup-configuration-help-cis-b137.0/-t108076.0.html
Posts: 23
Joined: 23 Feb 2009

micha--

> Is there a way to have it ignore the modification date?

You can compare by "File Content", but it is slow.
User avatar
Site Admin
Posts: 7170
Joined: 9 Dec 2007

Zenju

> Is there a way to have it ignore the modification date?

You can compare by "File Content", but it is slow.micha--
You can also compare by size only (but it's not a first-class citizen): see FFS help file chapter "Expert Settings: FileTimeTolerance"
Posts: 6
Joined: 5 Nov 2010

rizik29

New version of Comodo software was released, and it seems that problems are solved for other softwares (total commander now works without problems in copying files). But FreeFileSync (latest version 6.14) seems to be stuck with same problems as before. What's even worse is that after synchronisation with Microsoft Robocopy FreeFileSync shows that files are not the same even if they have same filesize and timestamp.
Is this issue going to be resolved anytime soon, or do I look for another software to replace FreeFileSync?
User avatar
Site Admin
Posts: 7170
Joined: 9 Dec 2007

Zenju

New version of Comodo software was released, and it seems that problems are solved for other softwares (total commander now works without problems in copying files). But FreeFileSync (latest version 6.14) seems to be stuck with same problems as before. What's even worse is that after synchronisation with Microsoft Robocopy FreeFileSync shows that files are not the same even if they have same filesize and timestamp.
Is this issue going to be resolved anytime soon, or do I look for another software to replace FreeFileSync?rizik29
What makes you think there is a FreeFileSync bug? File times can be verified externally, e.g. by checking with Windows Explorer.
Posts: 11
Joined: 26 Oct 2012

bkjhkjgjjkk4

I have the same problem - even when I disable COMODO completely, delete the backup and use mirror mode to create a new backup.

This is really nasty -.-
Posts: 11
Joined: 26 Oct 2012

bkjhkjgjjkk4

The current CIS version does no longer have this problem - at least, when the "feature" is disabled. I dont want to test whether the problem persist with the enabled feature.