• Content Count

  • Joined

  • Last visited

About syadnom

  • Rank
  1. touch changes the mtime, so when I touch the file it does trigger btsync according to the rules you outlined in the last post. btsync does actually transfer enough data to update the mtime on the remote side(s), it just doesn't update the sync time. Apparently unless file contents actually change.
  2. found a curious oddity in testing this. I can't just touch the file. btsync will replicate the timestamp without updating the last sync. I have to actually change the file contents to have it update the last sync time. Seems strange because it is actually replicating the file timestamp changes.
  3. more: 1) still dreaming of shadow copies! need to backup those locked files and pst files! 2) email notifications of out-of-date syncs. especially useful for using as a backup product as email notifications of syncs being out-of-date provides the ability to know that data is being backed up/synced! 3) store timestamp for last check or at least for last time client was visible/connected. this way we know that the remote side is up-to-date or how long it's been since we knew. critical for using as a backup product from an administration standpoint. ability to store .sync folders outside o
  4. I've synced up to 1.3TB with btsync (even pre-seeded the target) and it works fine, though I haven't done such a large amount of files. file permissions aren't going to come over for might have to backup the folder structure and permissions and transfer those first. not too big of a deal if your folders all inherit permissions but if you block inheritance or do anything advanced then permissions may be an issue.
  5. RomanZ, I've applied for an API key to get started. Here is my confusion on the 'Get folder peers', if the language matches the app gui, then last sync is the last time a sync was actually performed. If no sync was needed, then it doesn't occur and that timestamp doesn't get updated. In many circumstances, this works. What if a machine is online, but hasn't had any changes to a synced folder for 2 days. If I'm going to trigger some sort of response, I need to know that that machines at least checked in. I hope I'm making my need clear, I need to know that a device IS synced within 4
  6. Here is a really brief description of what I'm wanting to do: client machine>btsync>file server track when client's folder(s) is checked/checks for updated files track when a sync for each folder is completed. use this information to derive whether or not the client computer's share is synced or has been within some specified amount of time (say 2 days), store this on the server side/in *sql basically, I can query the file/database to see when folders are not backed up. the API has documentation on how to get a list of the hosts attached to each share, but I can't find anything on
  7. The BBB is MUCH faster than the Pi. Additionally, it's USB port is faster. 700Mhz ARMv6 vs 1000Mhz ARMv7 equates to about 2.5x the CPU performance. btsync will hash files faster and have better IO on the BBB.
  8. capability to 'view' a folder or rather mount a 'view' to the swarm using the read-only key. Use case is specifically to distribute videos and images across various computers but be able to watch or view the files via streaming. Could use this with Plex and mount up a read-only btsync folder as a library and watch from the swarm Secondly, +++++++++10000000 for shadow copy sync on locked files. The method I would prefer is to shadow copy the locked file and sync, then when the lock is released switch back to direct sync of that file. I believe that you can pull the diff between the shado
  9. I should have clarified. On Linux and I want to be able to see when each remote client last synced. This way I can see if they are up-to-date. This needs to be text values I can push into a database.
  10. I need something I can see when the last sync was. Basically, so I can check to see if remote devices have synced up recently. is this possible today with the API or can it be added?
  11. 2 requests in one, but they are related 1) Post sync commands. Whenever a sync completes, run a command. 2) Post sync shadowcopy. A checkbox that will initiate a shadowcopy on the shared folder after each sync. I realize this is Windows specific, but still very useful for many people. The idea here is that sometimes a file will get deleted from a sync folder and that deletion gets propagated out. A shadow copy makes that file recoverable easily.