Odd behaviour on first time synchronisation

[JeffCansell]

I'm setting up two-way synchronisation on a number of file shares.

When initially added, all files are copied from the source to the target (as expected) but when the profile next runs, everything is then copied back from the target to the source!

The cause would seem to be that the file timestamps aren't retained on the initial copy to the target therefore they are newer than the originals when the profile is next run.

I'm using 'Size and Timestamp' as the comparision method - should i switch to CRC or Both (or simply tick the 'Ignore Timestamp' option)?

[TGRMN Software]

CRC takes would take too long, what type of drive is the target?
It seems the target drive is not retaining the original file timestamps, and VV thinks the target files are newer. thanks
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

[JeffCansell]

Windows 2003 SP2, NTFS partitions for source and target.

NTFS permissions and ownership is carried over correctly (once options for this are set).

You are correct that it's the timestamp that is triggering the copying back from target to source (thereafter everything matches of course so it stops).

This is part of a failover design - DFS is used to connect users to the source location unless it's unavailable in which case the target is used instead. We are using sync in order that changes made to the target are replicated back to the source location when it becomes available once more.

I can't see any reason why viceversa shouldn't be used in such an application but am now considering using replication instead of sync (and manually restoring any updates to the source location).

A 2nd issue has become apparent - the profile run is aborted whenever any source location is found to be unavailable, we'd much prefer that the profile continued to run and sync'd whatever source locations were still available and ignored those that weren't - is this possible to configure?

Thanks.

[TGRMN Software]

Hello

Under profile settings -> folders , option "Continue even if some source/target folders are not available".
Or split the single profile into multiple profiles.

thanks
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

[JeffCansell]

I've tried the option suggested (I can't split the profile as I'm using VVLauncher which only permits one profile) but this just results in 'exit code 2' and nothing much else.

It is definitive that timestamps won't be copied between two NTFS partitions?

Thanks,

[TGRMN Software]

[JeffCansell]

The Exit Code 2 issue persists whether I run VVLauncher whilst logged on or as a service. I'm using UNC paths and a domain admin account in either case (Unticking the 'continue if some source/target folders are inaccessible' resolves this issue immediately).

As regards the timestamps, I am seeing some being retained but very few and i can see no pattern in what is occuring as regard particular file types. Folders always get the current timestamp when created on the replica however. It is the date modified that I'm referring to here (date created information is retained correctly).

I have the copy file/folder permissions and owner options set for NTFS.

A manual copy of the files from the source to the target partitions retains the file timestamps (although any folder will get the current time, files within the folder will retain the correct timestamps).

[TGRMN Software]

Sent you an e-mail
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com