nils
-
Posts
238 -
Joined
-
Last visited
-
Days Won
5
Posts posted by nils
-
-
It depends, if btsync discovers the VPS as a LAN client - which btsync determines with multicast messages, see the documentation on peer discovery http://www.bittorrent.com/sync/technology. If your openvpn is configured as a bridge and multicast messages, such as mdnsresponder etc come through and vice versa, then it should use the LAN IP. The sync.log should show the connecting IPs and I think they should be visible even without debugging.
-
So an option to force a RO sync to stay up-to-date is imperative!
Take a look at the advanced folder preferences at the RO node, you should find a checkbox named "Restore modified files to original version". (I assume you are using 1.2.71)
-
One thing that could impact your data transfer is the relay server, which is enabled by default for every shared folder. Some also had improved transfer speed when enabling TCP for LAN only syncs, see the advanced settings.
-
So it worked? I have iTunes 11.1.3 on both devices. But the MacBook Pro has Mountain Lion (10.8.x) and the Air Mavericks 10.9, can this cause the problem?
All I tested was if files were locked if iTunes was not running, I did not sync anything. You might have to take a look at "Enable debug logging" from the BTsync menu. The sync.log should be in ~/Library/Application Support/Bittorrent Sync/
-
Remember that Sync cannot sync files that are currently open/locked/in use by other applications.
You may need to completely close iTunes on your devices for all your files to sync
The files described by the OP are not locked if iTunes is closed, I checked with lsof in the terminal whilst running it and once when closed (iTunes 11.1.3, OS X 10.9).
-
I can confirm that this line appeared in my RO nodes' sync.log with a file that was excluded on the RW master, but synced to the RO nodes before. I put the file extension into my SyncIgnore file at a later state, therefore it was synced, and the RO nodes were trying to sync it because I selected "Restore modified files to original version".
I had to delete the conflicting file on every RO node before it disappeared.
-
It means, that the connection to this node uses the relay server set up by the BTsync guys. Sometimes a direct connection is not possible between nodes and if you have checked "Use relay server when required" in one of the folder's settings, that share will use the relay if necessary.
-
iOS client:
- Add the same features of the desktop app to the mobile app
- Settings per folder e.g. use TCP at LAN, Restore modified files to original version, QR code to let others connect mobile-to-mobile
- Device names
- Upload tab
- Enable deletion of files from the iOS surface on RW shares, not just "Cancel" or "Delete" from the device
Dekstop/webUI version:
- Allow creation of ENC keys with a user defined secret (through API?)
- Show a list of not yet synced files and therefore simplifying the identification of locked files from the UI without going into debugging, Could be integrated into the Transfers with an option "Show locked files" in the advanced settings.
Thanks again for the updates
Edit:
I reckon this has popped up a few times as well, as I have just seen another topic reply by GreatMarko regarding what Sync thinks are identical files:
"Identical" files to Sync have the same name, same size, and same timestamp. If one or more of these differs, Sync won't see files as "identical".
An implementation of SHA1/x MD5 file checksums and others would greatly help you identify e.g.:
- Do a comparison of checksums, maybe even database of checksum+file location in share?
- This would prevent problems with timestamps etc
Already implemented according to HaroldFeit
The files on both ends are hashed in semi-standard bittorrent fashion (segmented hashing with segment size based on total file size) and if the hashes are identical on both sides, the files won't actually be transferred.Edit 2:
Add a --debug option or -v -vv -vvv switches to the binary to turn on debugging for a session, maybe even a switch for demonising, as well as including these options in the config file.
- Add the same features of the desktop app to the mobile app
-
Got it working with a sample config generated with Python from another thread . My minimal config :
{ "storage_path" : "/Users/username/Library/Application Support/BitTorrent Sync", "use_gui" : true, "webui" : { "listen" : "127.0.0.1:8888", "api_key" : "XXX" } -
I have tried the same on 10.9, but was unsuccessful. Can one of you post a working config?
-
You can now browse through the files of a share with the get_files method and download them with the set_files_pref method. These are currently only available through the API. The methods are described in the documentation http://www.bittorrent.com/sync/developers/api
-
When you say "almost as much time", does it really download anything? If it does not download anything, BTsync could just take long for the indexing.
You could check in the GUI if there is any download activity.
-
It depends on how you "installed" btsync. If it is a service i.e. you start it through /etc/init.d, then maybe take a look at the script and change user and umask respectively. If not, then you could switch to the user www-data:pi with su and then change the the umask with the umask command.
-
Are the starting characters documented somewhere or are they a deduction from generating a lot of keys?
Deduction from generating keys with BTsync itself and also some comments seen on the forum.
The GUI does not create keys with ENC support, therefore the A and B secrets. The API is the only way to create shares with ENC capability for the time being.
From a business point of view it also makes sense, because this could be an enterprise feature, as API keys are needed to activate it.
-
I have a VM Superhub in modem mode running and a TP-Link N750 router with openwrt and everything seems fine. I have the 120/10 Mbit package and never had problems. I have to admit, that most syncing is going out only, as I sync my shared folders offsite.
-
If you look closely, the secret's first default character changed from Axxxxx (RW) and Bxxxx (RO) to Dxxxx (RW), Exxxx (RO) and Fxxxx (ENC), which means they are generated with a new function internally. In short, you can only enable encryption with new secrets. I also think this is a step backwards in making it impossible to create your own ENC nodes with a user supplied secret.
-
Forgive me if I'm being stupid but how does one go about setting this up?
I can only see the option for read only or read/write as usual.
it should read:
- Advanced features available through API:
- new secrets with support of read-only encrypted peers
- synchronize selected files only
- Advanced features available through API:
-
+1 for some sort of documentation for the API and advanced settings.
-
BTsync does not have such an option ATM. The user and group are the same as the one running the btsync process, you could however change the umask temporarily, see http://www.eupcs.org/wiki/UMask. I have seen settings on user and umask in the package that tuxpoldo put together for debia/ubuntu.
-
BTsync does not allow editing in the "cloud" i.e. User 2 editing documents on User 1's computer like you described it. For this use case I would recommend a network share or something similar that would expose your data to someone else, maybe look into SFTP/FUSE, NFS, Samba, AFP and similar things.
-
Indexing is known to take quite a while for a large number of files.
You can start the btsync client from the command line with a --config parameter and then point it to a config file, if you would like to configure it that way. This way you can either take part of the control away from the webui, or disable it completely by including shares and secrets in this file. The btsync binary can produce a standardised config file with --dump-sample-config. btsync --help shows you the currently implemented command line options as usual in Linux/Unix.
-
The files are in the .sync folder, however, they are not in a readable or editable format.
-
You don't get it.
I am not sure you get the nature of BTsync at its current state: a synchronisation tool (with minimalist backup .SyncArchive implementation). BTsync is not here to obliterate a good working backup solution, which would be able to prevent data loss as described in your case.
The first case of renaming files, which are added again, could maybe prevented by BTsync, if an md5/sha1 would be saved for each file, but that might blow up the database for large shares as well. In short, it is not an easy solution and should go into a Known issue part of the documentation for the time being.
FYI: dropbox known issues
-
BT sync's transfer speed might have something to do with the implementation. It is closed source and therefore hard to tell how it can be changed/improved, unless the debs make configuration options available. Other causes for slow speed could be on the ISP side, blocking and/or slowing down of P2P traffic.
SYNCING a folder from one iMac to another (CONNECTING the two)
in Sync General Discussion
Posted
Try this http://www.bittorrent.com/sync/get-started