prog9999

@RomanZ What do you mean "If reading the folder on both peers does not help?" Doesn't that happen automatically in Sync or is that something I have to trigger?

I upgraded to seperate installations from 1.3 to 1.4 and both had problems. One was a series of 6 folders. 5 of the six, which were small, converted with no problem. The 6th was about 133 GB and had to eventially be redone (disconected and readded). Even though the folders on the peers are about 99% identical, BTSync wants to resync them in total, it's still going today as I write this and has been doing so for about 2 weeks. The other installation is a single 600 GB folder and it is also about 99% identical on the peers. I don't expect this one to be done resyncing for another month. My question is why is BTSync wanting to resync everything again when almost everything is the same already??? P Prog

BitTorrent Sync is just a great program! I have run into one issue I don’t know how to resolve or maybe I am asking for a new option. And if I am posting this in the wrong place, I apologize. I backup a sever that is used for a Dental office that uses EagleSoft. Every so often the program rolls over a file (PattersonPM.log - contains a transaction history) when it gets to a certain size. This rollover happens when the database is started by essentially renaming the current PattersonPM.log file and creating a new blank PattersonPM.log file. The operation system (Windows 7 Pro) and BitTorrent Sync sense and react to the change so fast (seems shorter than the 10 sec I’ve been reading about) that the EagleSoft database can’t start up because the new PattersonPM.log file is in use by BitTorrent Sync trying to sync it. Is there a way that currently exists or could be added as an option to delay BitTorrent Sync from syncing immediately on sensing a file/folder change? This would be something different than the "folder_rescan_interval" setting, something like "initial_sync_delay". Again, thanks for the program and for looking into this! P Prog