I have a freshly formatted external USB hard drive. My main data drive is also an external USB hard drive. I configured FreeFileSync to mirror left (Main drive) to right (Backup drive).
After I ran the process for the first time, it completed successfully. Immediately upon completion of the sync, I ran the 'compare' process again. FreeFileSynce wants to re-sync every single file once again.
For some reason, the files copied to the right-side now have different and newer dates and times than the original files on the left-side!?
If I do a compare by content, everything is in sync.
Can you give me any suggestions as to what might be happening and how I can correct it?
I am running Linux Mint 14.
Cheers,
Dan K.
File dates and times do not match after mirroring
- Posts: 2
- Joined: 7 Apr 2013
- Posts: 2
- Joined: 8 Apr 2013
I have the exact same problem as Dan (I'm even running Linux Mint 14). Note that I've been using the Windows version of FreeFileSync for at least a year and this dates & times problem has never occurred. Hashing is not a practical option as one of the data sets has a 33GB disk image that is never altered and hashing that takes at least an hour.
So far I have used the following scenarios:
[1] Syncing between two NTFS partitions on a computer with Linux Mint 14.
[2] Syncing between two NTFS partitions on a computer with Windows XP.
[3] Syncing from a FAT32 Usb drive to an Ext3 file system with Linux Mint 14.
The date & time problem occurs with [1] and [3]. On Windows FreeFileSync changes the modified date of the synced file to the source file. This is not happening with the Linux version. Is there any reason why this could be?
Thanks,
Bart
So far I have used the following scenarios:
[1] Syncing between two NTFS partitions on a computer with Linux Mint 14.
[2] Syncing between two NTFS partitions on a computer with Windows XP.
[3] Syncing from a FAT32 Usb drive to an Ext3 file system with Linux Mint 14.
The date & time problem occurs with [1] and [3]. On Windows FreeFileSync changes the modified date of the synced file to the source file. This is not happening with the Linux version. Is there any reason why this could be?
Thanks,
Bart
- Site Admin
- Posts: 7281
- Joined: 9 Dec 2007
This is related to the following problem:
[404, Invalid URL: https://sourceforge.net/p/freefilesync/bugs/251/]
[404, Invalid URL: https://sourceforge.net/p/freefilesync/bugs/251/]
- Posts: 2
- Joined: 8 Apr 2013
Thanks Zenju, but what's the outcome? The package is there but it's for Ubuntu 64-bit, which is neither my distribution nor CPU architecture. I also noticed the bug was "closed", which is partly what motivated me to post here. Is there a plan to issue an update package?
- Site Admin
- Posts: 7281
- Joined: 9 Dec 2007
Of course, the update will be included in the next release, begin of may.
- Posts: 2
- Joined: 7 Apr 2013
Zenju,
I followed the other link you posted and downloaded the 5.15 beta version. I'm running it now. A quick perusal of the properties of some of the files that it has already moved shows that the file dates and times match on both sides.
Cheers for the quick fix. Thanks for you efforts.
Dan K.
I followed the other link you posted and downloaded the 5.15 beta version. I'm running it now. A quick perusal of the properties of some of the files that it has already moved shows that the file dates and times match on both sides.
Cheers for the quick fix. Thanks for you efforts.
Dan K.
- Posts: 1
- Joined: 4 Jan 2011
Has this been reverted in 5.16? I am running FFS on OS X 10.8.4 comparing to a server running Ubuntu 12.4 with a ntfs disk. Sync runs, no error messages and the time did not get changed.
This is from your changelog:
"Workaround silent failure to set modification times on NTFS volumes (Linux)"
Does this mean that the modification times are silently not set?
This is from your changelog:
"Workaround silent failure to set modification times on NTFS volumes (Linux)"
Does this mean that the modification times are silently not set?
- Site Admin
- Posts: 7281
- Joined: 9 Dec 2007
There hasn't been a change with regards to setting file modification times from 5.15 to 5.16 and the bug above affected Linux only, not OS X. Latter uses the canonical "utimes" to set file times, so one would expect that the network drivers correctly implement this function.
- Posts: 1
- Joined: 8 Jun 2013
I am currently using FFS version 5.15 on ubuntu 12.04 (X86) - The problem still exists which makes my backups (of 4TB disks) worthless! Please fix this bug!
- Site Admin
- Posts: 7281
- Joined: 9 Dec 2007
> The problem still exists which makes my backups (of 4TB disks) worthless! Please fix this bug!
You need to help a little: What are the conditions that reproduce this behavior? Does it depend on the FFS version, the backup medium you use, etc...
You need to help a little: What are the conditions that reproduce this behavior? Does it depend on the FFS version, the backup medium you use, etc...