New Members
  • Content Count

  • Joined

  • Last visited

About Brad@IO

  • Rank
  1. 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 i
  2. It would be good to have a clear clarification, but I guess for now we should assume that the problem still exists...?
  3. 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 folder
  4. 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
  5. Having read the forum postings and articles about IgnoreList (eg 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 m
  6. I've now got a file called sync.conf (attached) in %appdata%/BitTorrent Sync Service folder. It contains: "webui" : { "listen" : "" } 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
  7. 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. 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?
  8. @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?
  9. @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
  10. 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?
  11. 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.
  12. 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!