Mirror doesn't ignore unchanged files

[Sharpei222]

Help!

I have just run SyncBackFree a few times in mirror mode to mirror 50,000 image files from my external SSD (Samsung SSD) to my NAS HDD (WD My Cloud).

It took a day to run. There were 8 missed files in error log. These seem to be due to a momentary access problem but the 8 files are all available now.

So I thought I would re-run the mirror profile and it would ONLY update the 8 missing files. And only take a minute or two... But no, instead the SB pre-run log showed 50,000 "Collisions". So it seems like SB will spend another day copying ALL 50,000 files again even though 99.99% are fine because they were only just put there by SB yesterday.

The reason they are flagged for overwriting seems to be because they have today's date on them in the right panel (Destination disk / NAS HDD) but a date back in last November in the left hand panel (Source disk / SSD).

Why is this? I would have expected that successive SB mirror runs would only work on properly changed files, not ones whose only change seems to be the fact that they received a difference date stamp during the mirroring process itself.

Can anyone tell me if I can change some settings to avoid changing the bulk of the files that haven't actually changed?
cheers Andy

[Swapna]

Hi,

SyncBack (by default) in each run scans Source and Destination files to detect differences using last modification date/time stamps & sizes and copies only new or changed files from Source to Destination without overwriting unchanged files. However some devices e.g. NAS drives, FTP servers, Cloud servers have problems trying to correctly handle Last Modified date/time file stamping, which our programs uses as one of the method to compare files. Because of this, dates/times of files between source and destination would never match and makes file synchronization unworkable.

Try enabling the option "Force the file modification date & time to be correct" under:

Modify > Expert > Copy/Delete > Advanced settings page

to force-set the Last Modified date/time stamp of a file, but there is no guarantee all devices support it.

If it doesn’t work then the only option is to use Fast Backup mode supported in SyncBackPro/SE and never force a re-scan. If you do not own a copy of SyncBackPro/SE and wish to test its functions, you are welcome to try our fully functional SyncBack, which we offer a free 30-day evaluation.

http://www.2brightsparks.com/assets/sof ... _Setup.exe

http://www.2brightsparks.com/assets/sof ... _Setup.exe

If you do decide to purchase, the serial number will convert the 'trial' to the 'registered' version.

Please read these forum posts for additional details:

viewtopic.php?t=12613

viewtopic.php?t=11931

Thank you.

[Sharpei222]

Dear Swapna,

Thank you for your comprehensive reply. I was just coming to same conclusions myself after racking my brains and looking at the files. I have used SBF before and never had this problem. It is clearly using the "WD My Home Cloud" NAS that has caused the change.

There are two issues actual/possible:
(1) repeated long (and more error prone) "first day" backups due to this date issue - an actual problem. This is a pain but there are manumatic ways round this.
(2) possible problems in Adobe Lightroom software if the backups need to be restored and used, due to image modification dates changing. I am not sure about this but I need to check this. This would be a more serious error of the two.

I will run some tests now and get SB-SE trial to see how it behaves in these other modes. And I will also see how Lightroom deals with the files produced eg if EXIF and metadata gets changed. (I set LR to write metadata changes into XMP files so I am hoping this is not an issue).

regards Andrew