ExtremeSync Service not picking up all changes

[MRSchexnayder]

Hi!

I've purchased this software for a number of systems for my company and am using it primarily to keep our webservers all on the same page.

Currently I have a copy of the software running on multiple machines were they access a central directory structure for replication. I've setup the jobs to be "Real-Time" so that any changes on the source are auto replicated to the other servers. However, I find that it may not catch all the changes and I have to go back occassionally and run a full sync. Is this an expected behaviour or a bug?

To get around the issue right now, I've added scheduled syncs every 3 hours to each of the jobs.

Thanks for your help!

Micheal R. Schexnayder
Build-A-Bear Workshop, Inc.

[superflexible]

Hello,

yes that's correct, there is no guarantee that all changes are noticed in real-time. It depends on the real-time notifications that the Windows file systems send around, and these may be incomplete, especially over a network. So, a regular schedule like every couple of hours is indeed necessary.

Best wishes,
Tobias Giesen

[Ivangelion]

yes that's correct, there is no guarantee that all changes are noticed in real-time. It depends on the real-time notifications that the Windows file systems send around, and these may be incomplete, especially over a network. So, a regular schedule like every couple of hours is indeed necessary.

I am having the same problem here. Could you please elaborate the detailed cause of this kind of problem? Our company is surveying a robust & reliable file sync software, and this issue would be a minus to use SFFS if I can't explain it to my fellows.

[superflexible]

Real-time processing handles those files and folders for which Windows issues real-time notifications. But Windows does not do that always. It usually works 100% reliable with local hard drives. It never works with NAS devices not running Windows.

In addition to real-time, you must schedule a regular synchronization such as every hour or once during the night. If such a full sync takes too long, there are ways to speed it up. Please see also http://www.superflexible.com/docs.htm (Q: "Building the file list takes too long")

[Ivangelion]

Real-time processing handles those files and folders for which Windows issues real-time notifications. But Windows does not do that always.

Thank you for your fast reply. I was wondering under what condition doesn't Windows issue a real-time notification to the remote machine? The last time real-time sync had a problem is that I deleted two files, only one got deleted on the remote side.

[superflexible]

Real-time notifications are a mere courtesy by Windows and the file system drivers, and I do not think that definitive information is available anywhere.

But concerning the deletions, it could be that one of them was not executed for other reasons. To analyze that, you need to look into the log files. The real-time notifications are listed in each log, and also how they were interpreted and processed. If you have questions about a particular log, you can send it to info@superflexible.com.

[superflexible]

For example, on the Real-Time Settings dialog box, there is a default delay for deletions of 10 minutes. You may want to reduce that. Also deletions are not even enabled by default. You need to explicitly enable them on the Real-Time Settings dialog. This dialog will be shown when you click on the real-time checkmark once more, even if it is already checked. It will stay checked and the dialog will pop up.

[Ivangelion]

I've already turned the delay time to 0 minute to achieve real-time sync.

Also, I found that log files of past year (2010) were all gone! Does the program will delete log files of past year automatically or I mis-configure something? I've set the number of log files to keep to 300, and the current number of log files of that profile is 109 only.

[superflexible]

The program will not delete last year's logs. I don't know why you don't see them. Maybe the log folder has changed. This could happen if the job is run by a user that does not have write access to the folder, or if you change the log folder manually. You can see the current location on the Program Settings dialog.