• Content Count

  • Joined

  • Last visited

About rickard@linri.se

  • Rank
    New User
  1. Just wanted to add another (similar) usecase to this story. I have set up syncing of my production areas over several servers (I work as a developer). The idea is that all these different areas should always have the latest code, and also be versioned/archived for a period of time. This works wonderfully well with Resilio even though I have thousands of folders and hundreds of thousands of files monitored. The only hickup (and I have mentioned this before) is the problem with locked files. Most often, when Resilio is active, I will be unable to compile as the target .exe file is locked, syncing to some server over a fairly slow line. I usually pause syncing then, but it is bothersome and kinda goes against my idea of always having an identical copy somewhere else. I forget to unpause syncing. A solution - if shadow copying doesn't work out - is the copy the file to a temp folder before uploading it starts. To make that even more clever, Resilo service could then monitor the original file as the copy is being uploaded, and if the original file is modified, the upload could cancel and restart using the modified file.
  2. When syncing files on Windows (possibly on other platforms as well) the file currently syncing is opened denying write access to other processes. This is ofcourse natural, but let me describe my use case and then explain my suggestion. I have set up BT Sync on several computers and devices both to achieve a constant back up, but more importantly distributing my project files so I can (almost) immediatly go to another work place and access my updated files there. BT Sync is the only tool that has a fast enough indexing function to achieve that, that I have found. I have hundreds of thousands of files covered by BT Sync but still, changing a random file will almost immediatly sync it to my other work places. This is awesome and very unique. My problem is that while BT Sync is working on a file, it is locked. So compiling my project will fail if BT Sync happens to be working on the .exe (or debug map files) of that specific project. As these files can be anywhere between 50 and 100 mb when compiling them with debug info (and I have some rather slow links on my network) this can be anoying, and I usually pause the sync (which will stop syncing the file, but annoyingly continuing to index and notify my of locked files). My suggestion is to look into the possibility (and ofcourse implement it if possible) of creating a local copy of the file to sync BEFORE it is synched, and then read from the created local copy. That will make the locked time much shorter and allowing the user to keep on working on his or her project without interference from BT Sync. The fact that it is not the absolutelly latest file beeing synced doesn't matter I think. BT Sync could abandon the sync if it detects a new version of the original file, or simply pick up the changes in the next indexing cycle.