nils
-
Posts
238 -
Joined
-
Last visited
-
Days Won
5
Posts posted by nils
-
-
@elpo RTFM, thank you
Yet, I would have expected this to be mentioned in a changelog and not just a README? I updated from 1.4.83 to 1.4.9x and this was not explicitly mentioned.
-
Since version 1.4.9x the web ui on FreeBSD does not seem to work any longer on the default port 8888. Any thoughts on this?
EDIT: I tried lynx on the console of the FreeBSD server running btsync and was able to get a connection with cookie prompt on 127.0.0.1:8888 (no UI though), but no connection on that port for the external IP.
-
The UI problem, where the main window can be resized and then hiding the share and pref buttons on the far right.
NB: I reckon this has been mentioned before, but the 1.4.x UI window is horrendously large on machines with small screens e.g. 13", taking up almost the entire screen. A setting for text/general size would be a nice-to-have. -
In OS X, it seems resizing can hide the rightmost icons for a share i.e. the share button and the three dots for preferences. This seems like a bug or should be fixed. I would not expect these to disappear when shrinking the main window.
-
Now with 1.4.xxx, i have to put this in ignorefile or streamlist ?
into the IgnoreList file. Also delete/comment out the streams in the StreamList files, to make sure that the streams are not included (not sure if BTsync handles this automatically or prioritises the IgnoreList over the StreamList, therefore deletion of streams will make sure it stays the way you want it)
-
Some thoughts on the new WebUI:
- It is nice to see a convergence of UI elements, in this case the folder icon on the UI matches the iOS version, making it easier for new users.
- I do not understand, as already said, why the overall upload/download is at the bottom of the page. E.g. if someone has a lot of shares, the user will only find out about this by scrolling down. Why not implementing this at the top at the same level as +Add Folder and Preferences.
- The mouse-overs are nice, but I would still like the ability to see the same info per each share as before: connection status: direct/through relay, upload and download rates per each connected device.
I know, that you are probably trying to make the UI as similar as possible, but it seems this UI is going one step forward in UI alignment and two backwards in terms of usability.
-
So in a nutshell, I'll always need a desktop since they are the only ones who can generate the secrets and allow the connections to happen?
Half and half: yes, you need a desktop to set up the share, which you then connect with your phone through a QR code. once you have done this, you could theoretically delete the share on the desktop and have it only running from your phone. Then you can connect new smart devices from your phone to the same share. You do not need to have a desktop/server version running in order for the phone node to work on its own.
-
Although the mobile app versions support connecting with QR codes, they are not capable of creating their own shares. There used to be a quick method of sending files with mobile devices by selecting some files and creating a temporary secret, but this feature was unfortunately removed a few versions ago.
-
Disabling DHT, tracker and relay should do the trick. If you want to get even more restrictive, disable LAN search and then enter the IP and port in the defined hosts setting. This should give you a LAN only sync.
-
The setting you are looking for is called folder_rescan_interval and accepts values in seconds e.g. 600 = 10 minutes (also the standard value). You will need to use a config in conjunction with the btsync command. If you call the btsync binary from the CLI with the option --dump-sample-config you can get a config template and continue from there.
-
In particular, since I'm syncing from OSX to Linux I'd like to turn syncing of extended attributes off until it works.
I have disabled them in each share by excluding the streams listed by @RomanZ in my .SyncIgnore. The reason for this was the incompatibility of streams on cross platform shares, e.g. OS X xattr cannot be written on FreeBSD fs.
-
- Scan QR codes on desktop version
- get back the option to see and copy the read only secret in the iOS Photo Backup. Sending an email should not be the only option. (yes, I can create an email and copy the secret, but I liked it the way it was before.)
- get back the quick sharing function in the iOS version, which enabled ad-hoc creation of sharing files with mobile users.
-
If you have 3 peers, 2 Macs and 1 Linux - Macs will sync xattrs successfully. But they will fail to sync their xattrs to Linux machine. There is a certain limitation on Linux PCs how xattrs should be named, so Mac names for xattrs does not conform Linux demands.
In the API, the BTsync node's OS can be identified. This information could surely be used to discern between xattr supporting and non-supporting OSes and make the syncing behaviour change accordingly.
-
There isn't any way to only synd added files? So when I add files they are transfered but when I remove them they stay on the other side?
To my knowledge this is not possible with the current desktop version of BTsync. However, when looking at the iOS btsync client, the camera backup works that way: cow can delete camera photos on the iPhone, and they will stay on the receiving end, which is a RO client. I would very much like to see this behaviour implemented in the desktop app, as this could then easily be a backup node, where files get dumped and overwritten only, but not deleted if removed from the master.
-
If that's the case then how will they get the latest version then? Or how do they make it so that they get updates on those files again?
Unless the other person has selected "Restore modified files to original version" in the Advanced settings of that share. In this case, the other person's sync will keep in sync with yours.
-
Although it is a long thread, the devs do take notice of the requests in the Wishlist thread.
-
iOS client (currently latest 1.3.25):
- I am not sure if it might have been slightly before, but there used to be a quick share option, which created a temporary share to exchange files between mobile devices. Why has this been scrapped, please bring it back, as I saw this as a viable if one is on the road and wants to share files quickly.
- Thank you for adding QR codes on the iOS client, now I am able to connect other mobile devices with it as well. My wish now would be to add the option to generate a secret to set up a share initially on a phone. I have tried to input some random characters, but it keeps coming back as Invalid Secret.
Desktop (Mac):
- Make it optional to show the full path or have a mouse over/tooltip
- Add sorting to lists, alphabetical for names, numerical e.g. for the share size
Linux/Unix:
- Make the config file the same for webui and manual operation, instead of using a database file when using the web ui.
-
How can I increase the limit?There currently is no setting to increase this value. Maybe add it to the wishlist thread, encouraging the devs to take it into consideration in future releases.
However, it seems strange, that new peers are not able to sync with other peers. Are they all restricted i.e. by having defined hosts?
-
Hello vocatus,
If memory serves me right, the maximum number of peers a single btsync instance can concurrently connect to is set to 50. This should not be a problem in a peer to peer network, as files should not be synced from a single location only, if a lot of peers have the same secret. This in turn spreads the network load.
In your case, you deploy packages i.e. all the nodes use RO packages, which should not be a problem if they are not connected to you, as they should connect to each other.
-
There is one interesting release related issue here.
In my experience and understanding, beta is basically a nearly stable official release of the product.
At beta phase, no new bells and whistles are added and no new functionality and, especially, the changes of behavior are to happen.
The very definition of term beta is bug fixes ONLY. It is a final problem resolution phase of the product.
So, to me, to call this product beta stage is simply misleading.
So, if BTSync still continues to develop and/or add all sorts of new bells and whistles, for marketing purposes or otherwise, it would be more appropriate to reclassify BTSync as Alpha state.
In beta state, you are dealing with basically a releasable product where only the final touches remain in terms of fixing bugs ONLY. It is a state of the product when massive testing occurs with all sorts of test suites or otherwise.
Thank you for highlight this, I for one did not know this. I think the marketing devision at BT has to change from the terminology of "beta" to "perpetual beta" instead.
-
Hi MrFish,
I think it is the same issue that I have with the extended attributes, which are turned on by default to sync from the Mac since 1.3.67. A remedy might be to exclude these streams on the Mac master shares in the .SyncIgnore file, as described in my post here . This is only a short time fix, as some users would very much like xattr to sync as well.
HTH
-
Excluding the extended attributes is definitively not an acceptable solution.
I concur, this is not a proper solution, so it needs to be ironed out by the BTsync devs. But for the time being, I am able to use my shares with this "quick'n dirty" solution and others might be able as well i.e. not using xattr in a mixed environment.
-
That is why I have excluded them in my .SyncIgnore on the Mac, as I am mainly syncing with FreeBSD servers for backups and do not need the xattr
com.apple.FinderInfocom.apple.metadata:_kMDItemUserTagscom.apple.ResourceForkcom.apple.metadata:kMDItemFinderCommentcom.apple.metadata:kMDItemStarRatingcom.apple.metadata:kMDItemOMUserTagTimecom.apple.metadata:kMDItemOMUserTagscom.apple.metadata:kMDItemOMUserTagTime
Since then, all shares are syncing without problems.
-
@RomanZ:
The config file already use JSON formatting i.e. it should be editable with some kind of library for config files.
Is it not possible to make changes from the UI, which then get saved to the clear text file, rather than as a database? Vice versa, when I make changes to the config file whilst running btsync, changes could get parsed as soon as atime/ctime/mtime etc change.
Remote Copy Of Time Machine Backups
in Sync General Discussion
Posted
You could have a netatalk share as Time Machine network backup drive and then on that machine have a sync instance running, which backs up your data offsite. In addition you could then set up a VPN allowing you to make ™ backups on the road (given the internet speed is fast enough). With this, you get a nice networked solution, which itself is then synchronised to another server. This will alleviate your problems with users on the Mac, as you could easily run the btsync instance with the same user that has access rights on the netatalk server