syadnom

Members
  • Content Count

    12
  • Joined

  • Last visited

About syadnom

  • Rank
    Member
  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 of synced directory... maybe make an automatic folder for each host pair to store this. examples %username%/.btsync/.sync_foldername_remotehost the issue here is as follows: 1) if the folder is read only then btsync can't share it because it can't write the .sync files in the folder 2) if we wanted to sync a vss (for example, link most recent shadow copy to a folder like c:\vss\foldername) we can't because the vss is read only.
  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 sure...you 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 48 hours. If they synced 60 hours ago and havent needed to sync, I need to know that they are still in sync. Else, I might be hunting down a machine for not syncing even though it doesn't have anything new to sync. in a nutshell, I need a timestamp of 'last seen' so I can extrapolate that they are in or out of sync. Also note, I want to do this all 'target' side. I don't care to run scripts on the workstation, I only want to on the machine(s) that will handle bulk storage.
  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 how to find out when the last time those hosts 'checked in' a critical part of backups is knowing that they are actually being completed. additional info just for fun: server side storage is on a ZFS file system and snapshots will be made there. I don't need .SyncArchive. I will have a local cache onsite with a low power machine+usb disk (non-redundant, literally a volatile cache), possibly on a beagle bone black or pi. This way I can share out the cache and enable file history for windows clients so restorations are seamless. the missing part of the scenario is determining when a client has actually completed it's backup(s). also, I have considered just putting a scheduled task on the workstation to write to a .track file into the root directory of the local folder and then just using 'find' on the server and parsing out the results but this is a bit less that ideal, if btsync would just update such a file per folder for me as part of the .sync* files then I would be ecstatic. Thanks
  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 shadow copy and 'live' without having to hash the whole file through a .net library.
  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.