Can you change the "10 sec delay on file change"

[nuclearcanary]

I am looking into using BitTorrent Sync as a communication layer between remote processes. This communication layer will create very small files once and not modify them after that. I have a system running right now but since the sync starts 10 seconds after changes are detected, it is always living in the past. This communication requires that the changes be propagated as soon as possible.

Is the delay between changes detected and sync started configurable?

I have looked at the forums, guide and the FAQs and have not found where it could be configured.

Any help would be greatly appreciated.

[Datapotomus]

Have you tried changing the folder re-scan interval to like 1 second to see if it can fix your issue?

[nuclearcanary]

Yes, but right now I am running on embedded processors and did not want to task the CPU too much. I could have several directories running at once. I am assuming that BitTorrent Sync uses inotify on linux so that should not be too heavy.

[Harold Feit]

The delay of the notification code in your device is caused by a delay in inotify IN your device.

Sync gets notified by the operating system of changes.

Outside of that, re-checks happen every 10 minutes by default.

The root cause of your issue is in the inotify delay on your device.

[nuclearcanary]

Just to be sure, I tested this. I set up inotifywait on a BitTorrent Sync directory, then moved a file in. inotifywait returned immediately, while it took 10 seconds for Btsync to start the sync. I know this is expected behavior from this post.

Real-time monitoring works on all the platforms (delay on file change is 10 seconds). The only exception is OS X 10.6 where real-time sync can be delayed due to certain system limitations.

I have worked on file sync programs before, and this is typical. This is a settling time to allow disk activity to halt before beginning sync. My use case is a bit extreme as far as what I am expecting the program to do, but so far the only hold-up is the 10 second wait.

[joe@shopsbee]

I'd also like to see the delay changed for predictably small files (perhaps by extension) like .txt or .html .css .js .tpl to 2 seconds or less from the current 10 seconds, if possible.

[nonam]

Have you guys found a solution yet? I'm willing to invest some money into a BTsync (like) software that does faster sync (below 1 sec).

 

I'd also like to see the delay changed for predictably small files (perhaps by extension) like .txt or .html .css .js .tpl to 2 seconds or less from the current 10 seconds, if possible.

 

 

I am looking into using BitTorrent Sync as a communication layer between remote processes. This communication layer will create very small files once and not modify them after that. I have a system running right now but since the sync starts 10 seconds after changes are detected, it is always living in the past. This communication requires that the changes be propagated as soon as possible.

Is the delay between changes detected and sync started configurable?

I have looked at the forums, guide and the FAQs and have not found where it could be configured.

Any help would be greatly appreciated.

 

[GreatMarko]

Have you guys found a solution yet? I'm willing to invest some money into a BTsync (like) software that does faster sync (below 1 sec).

 

Essentially sync <1 sec isn't currently possible for the reasons outlined in this post from earlier today.

 

(It's always worth doing a quick search of the forum first before posting into a dormant thread such as this one!)

[nonam]

Essentially sync <1 sec isn't currently possible for the reasons outlined in this post from earlier today.

 

(It's always worth doing a quick search of the forum first before posting into a dormant thread such as this one!)

 

I know that it is not possible, that is why I ask here wether someone found another way to achieve what we need.