Brad@IO

That response doesn't clarify where we are at regarding older files overwriting newer files in Advanced folders. There's an increasing number of companies we deal with where discussion of Resilio sync comes up as an option and we always mention the problem with older files overwriting newer ones. It would be great to be able to know that issue has been 100% fixed, with no caveats. Are you saying: the issue with standard folders discussed in the thread is fixed but the specific known issue with Advanced Folders referred to by RomanZ still exists or the specific known issue with Advanced Folders referred to by RomanZ is fixed but overwriting of new files with old still occurs with Advanced Folders due to other known issues there are NO known, reported or outstanding issues regarding overwriting of new files with old in Advanced folders. Is the answer 1, 2 or 3? Or, if it's easier: As previously stated, we just want to know: Can we use Advanced Folders without the risk of older files overwriting newer files. Is the answer Yes or No? I can start a new thread if it will lead to a clear YES or NO answer.

It would be good to have a clear clarification, but I guess for now we should assume that the problem still exists...?

Hi Guys, bumping this old thread to see if there's new info. When I had problem with older files overwriting newer ones back in Oct 2015, RomanZ, confirmed that the issue <snip>...was fixed for Standard folders in 2.2.5 (while still exists for Advanced ones - its a bit more complex to fix it for advanced folders). As a result we've never used Advanced folders, but we would like to be able to take advantage of them. I've scanned the change logs several times since, but been unable to find any mention of a specific fix. Is this issue fixed for Advanced folders now? cheers

Thanks Artem. You've saved me again. :-) BTW thanks for the windows service fixes and also 2.3.2 fixed the RAM usage on the NAS. cheers

Having read the forum postings and articles about IgnoreList (eg http://help.getsync.com/hc/en-us/articles/205458165-Ignoring-files-in-Sync-Ignore-List- and others), the wording leaves it unclear about the behaviour on existing syncs and propagation of the IgnoreList file itself. ie "How do I stop syncing certain files on EXISTING syncs?" Say I've realised that *.pyc files are syncing unnecessarily. I want to stop this on all the peers with that sync (BTW all read/write and all running via BTSYNC WINDOWS SERVICE). So my questions are: If I change the IgnoreList file on my peer now, will that be applied IMMEDIATELY to my peer and then propagate automatically to the other peers so that *.pyc files will not sync between any of the peers? or, do I need to stop and then restart my BTSYNC WINDOWS SERVICE so that my IgnoreList will be applied and then propagate to the other peers? or, do I need to DISCONNECT and then RECONNECT the folder on my PEER in order to propgate the IgnoreList? or, do I need to DISCONNECT and then RECONNECT the folder on every peer in order to propgate the IgnoreList? or, do I need to manually update the IgnoreList on every peer? and, if I had added *.pyc to the IgnoreList file when I created the sync, would that have propagated to all peers that connected?

I've now got a file called sync.conf (attached) in %appdata%/BitTorrent Sync Service folder. It contains: "webui" : { "listen" : "0.0.0.0:33333" } You can see from the attached screengrab BTsync is NOT using the port specified (BTW there is nothing else using 33333) ( 4th column Local Port, 5th Local IP) None of the other IP addresses or ports that BTSYNC is using allow me to reach the webUI... So, here's where I get confused... %appdata% is for individual USER information and the point of a windows service is usually that it runs regardless of which USER or no USER is actually logged on - it's using the Local System login (ie NT AUTHORITY\SYSTEM). In this situation, normally the config file would be located in %programdata%/BitTorrent Sync Service. Why is this not the case with BTsync? I have tried both locations of the config file with no effect. I've also tried to have the service run with my login, but get a services error - "Error 1: Incorrect function" (see attached). I've also tried to manually add /config sync.conf to start parameters for the service but with no luck. I would suggest again to create a single clear and comprehensive article on how to install and configure the BTSYNC WINDOWS SERVICE option - including running in configuration mode etc. This article should clearly delineate how the setup or configuration differs from the "classic" BTSYNC approach. At the moment, queries are being answered in separate forum threads with links to http://help.getsync.com/hc/en-us/articles/204762689-Running-Sync-in-configuration-mode as reference for running in config mode...except the key point (4 - below) about how to start BTSYNC in config mode does not work with programs running as services. 4. Open Command Line Interface and execute the following command: btsync.exe /config btsync.conf It would be really helpful to have clarity on what log on settings are required in the service properties, where the config file should be located for those situations etc as I've tried many variants based on mixing instructions from several forum posts and articles, but none of them work. Thanks. sync.conf

I've just worked out how to get 2.3.1 to run as a service (update doesn't offer option, need to download the full install package and install over the top to get the service install option - might be worth mentioning this somewhere obvious as I googled and searched these forums without success). So now it's running as a service but I can't access the webUI at all. http://127.0.0.1:8888/gui/ just produces a 404 error. I don't have any config file that would change ports etc, so what do I do now to see what's syncing?

@romanZ: Interesting. We've always picked STANDARD when we add a share, but it seems they've all been set up as ADVANCED folders. Maybe because the share window next presents a permissions option before you share the link. Am I right in thinking that if we see this permission option then we're setting up an ADVANCED folder? @great marko: found the manual instructions for updating BTsync on the Synology NAS. Done. Happy to test again, but will that only be useful if the folers are converted-to or re-shared as STANDARD?

@great marko: The windows peers are running 2.2.5, but is there a simple method for updating the version running on the synlogy NAS? I haven't been able to work out how to update that "package" so far from 2.0.93. @romanz: standard folders AFAIK

Any news on this? I've just discovered this massive bug and it's easily reproducable. It's a catastrophic scenario. New peers added with older versions of files simply overwrite all newer instances of those files on all peers! Wow. It's got nothing to do with clock syncing. Our tests have shown 10 year, 1 year, 1 month, 1 day, 3 hour old files overwriting files that are less than 10 min old. There's no hope of using BT sync in any kind of professional environment with this sort of issue. Can we get a formal response about this issue from support?

OMG. If that's the case then have the CREATED time stamp set to the MODIFIED of the original file... ..or put the original file's MODIFIED timestamp as a string appended to the filename... or.... Any alternative suggestions? I think the intent of the request is clear.

Currently, archived versions of files have their original created, modified and accessed timestamps all replaced by the time that the file was archived. While it's useful to know the exact moment the file was moved to the archive, can the MODIFIED timestamp be retained to allow an historical breadcrumb trail? cheers!