bi-directional sync is stacked by changing files

[yoshy64]

First of all, thank you for this extremely useful tool.

I have a trouble to sync bi-directionally two folders with large video files over WAN using RealtimeSync 6.8 on Windows7.

The trouble is caused by video files when the files are creating and increasing sizes. The creation of the files may take few hours based on the video programs. Once a video file is started to be created, RealtimeSync invokes FreeFileSync to start syncing. It copies only the current portion of the increasing file and end syncing.

Because the video files increasing after the end of FreeFilesSync, RealtimeSync may invokes FreeFileSync again. However, FreeFileSync ignores the video file from files to sync. This causes the video file remain different.

FreeFileSync ignores it because FreeFileSync finds both files on each site changed separately after the sync.

I have to run FreeFileSync GUI manually, then I have to force to mirror such ignored files.

Are there any solutions to complete sync automatically by using RealtimeSync?

Thank you.

[Zenju]

If I understand you correctly, the following happened:

1. a file is in the process of being written on a network location
2. RTS detects a change and starts up FFS to run the "Two way" sync variant
3. FFS copies the incomplete file (this is possible since you have VSS enabled in global settings)
4. the file is finished being written to on the network location
5. RTS detects a change again and starts FFS
6. FFS detects a conflict "both sides have changed" for this file.

If this is the sequence, then the problem is step 6. I see no reason why FFS should detect a change on the other side of the folder pair. The only one writing to the target location should be FFS, so there can't be a conflict. Consequently further analysis must find out what other than FFS changed the file on the target side.

[Zenju]

If you can reproduce this problem up to step 6, then send me both sync.ffs_db files from source and target and also the metadata(size, modification time) for the file in question on local and network drives. Than I can check why FFS found a change on either side.

PS which version of FFS are you using?

[yoshy64]

If I understand you correctly, the following happened:

1. a file is in the process of being written on a network location
2. RTS detects a change and starts up FFS to run the "Two way" sync variant
3. FFS copies the incomplete file (this is possible since you have VSS enabled in global settings)
4. the file is finished being written to on the network location
5. RTS detects a change again and starts FFS
6. FFS detects a conflict "both sides have changed" for this file.

If this is the sequence, then the problem is step 6. I see no reason why FFS should detect a change on the other side of the folder pair. The only one writing to the target location should be FFS, so there can't be a conflict. Consequently further analysis must find out what other than FFS changed the file on the target side.

Thank you for your replay.

There is no problem when things done as the steps you wrote. However, the problem occur when the step 4 happened before the step 3 as follows. It often occur my environment because the WAN connection speed is slower than local file writing speed.

1. a file is in the process of being written on a network location
2. RTS detects a change and starts up FFS to run the "Two way" sync variant
p-4. the file is finished being written to on the network location
p-3. FFS copies the incomplete file (this is possible since you have VSS enabled in global settings)
p-5. RTS doesn't detect a change again and doesn't start FFS

PS. The FFS I'm using is also version 6.8

[Zenju]

Thank you for your replay.

There is no problem when things done as the steps you wrote. However, the problem occur when the step 4 happened before the step 3 as follows. It often occur my environment because the WAN connection speed is slower than local file writing speed.

1. a file is in the process of being written on a network location
2. RTS detects a change and starts up FFS to run the "Two way" sync variant
p-4. the file is finished being written to on the network location
p-3. FFS copies the incomplete file (this is possible since you have VSS enabled in global settings)
p-5. RTS doesn't detect a change again and doesn't start FFS

PS. The FFS I'm using is also version 6.8

In your first post it seemed you noticed some kind of conflict that you needed to "force sync manually".
-> this should not happen and I would consider it a bug - unless you have another application write to the file on the backup drive that FFS saves to.

In this post you seem to describe a different problem. Nameley that RTS does not detect the write finished event when FFS started copying a partially written file that takes longer than mentioned write finished event on the monitored folder.
-> The event is not detected because RTS is inactive while FFS is running. Solution is to turn off VSS in FFS's global settings.

[yoshy64]

In your first post it seemed you noticed some kind of conflict that you needed to "force sync manually".
-> this should not happen and I would consider it a bug - unless you have another application write to the file on the backup drive that FFS saves to.

In this post you seem to describe a different problem. Nameley that RTS does not detect the write finished event when FFS started copying a partially written file that takes longer than mentioned write finished event on the monitored folder.
-> The event is not detected because RTS is inactive while FFS is running. Solution is to turn off VSS in FFS's global settings.

Would you let me know which setting turns off VSS in FFS?

Thanks

[Zenju]

Would you let me know which setting turns off VSS in FFS?

Thanks

menu -> options

[yoshy64]

menu -> options

You mean check off the "Copy locked files" check box on "Options" dialog box ?

[Zenju]

You mean check off the "Copy locked files" check box on "Options" dialog box ?

Yes