trevellyan
-
Posts
142 -
Joined
-
Last visited
-
Days Won
2
Posts posted by trevellyan
-
-
So folks, I have a very stable release of 1.3, one of the last ones. Should I upgrade to 1.4.103 for all my devices
I don't see sticking with 1.3 as an option. Recent releases of 1.4.x have fixed bugs that would likely result in data loss in earlier versions (see the release notes for details). However, I agree with @sfmcnally regarding the upgrade process from 1.3.x to 1.4.x not being smooth. For me the best outcome was from a completely clean install of 1.4.x, after removing all trace of 1.3.x from all peers. It's a drag, but I think it's worth it.
-
The folder can exist on the local machine, but it shouldn't already be set up in Sync.
-
I see nothing obviously wrong with the process you described, but it doesn't match your screenshot. The dialog you posted is for updating a key for an existing folder. Have you tried removing the folder from Sync on the PC, then using the Enter a key dialog to start over?
-
I would not choose to sync an entire drive.
In my view, synchronization is not backup. I sync specific folders for which near-real-time synchronization is useful. I use backup solutions for backups of entire drives. In either case, it often make sense for a NAS device to be involved.
One reason I started using Sync was for the flexibility of being able to sync specific folders to specific devices, without having to reorganize those folders and without having to make do with all-or-nothing on every device. As you point out, these advantages are lost when syncing an entire drive, not to mention the performance implications.
If the drive happens to be where things like Windows user folders are stores, there are technical reasons not to sync the entire drive (or even entire user folders), related to where Sync stores it's internal data. But from the way you describe your setup, it doesn't sound like that's what you're doing.
Or can you still share a specific folder from within a main shared folder?
Nested folders are possible if all are shared read/write with all devices.
-
Are you by any chance attempting to use nested folders, i.e. trying to sync a folder that's inside another synced folder? Sync only permits that when the folders are read/write.
-
how would i go about changing the config?
Start here: http://help.getsync.com/customer/portal/articles/1672241-guide-to-linux?b_id=3895
-
Different versions might cause a problem. I'm still curious to know exactly how Sync responds when it refuses to accept the read-only key, since this is something I haven't seen.
-
Are you using the latest version? Is the destination folder empty? I think some versions won't let you use a read-only key if the destination isn't empty.
Exactly how does Sync respond when you enter the read-only key?
-
On the NAS web surface I do not find any button to remove a share. What am I missing here?
In the web UI, when you hover your mouse over a folder, you should see a Share button in the right column. Next to that button is a button with three dots in a vertical line. Click the button with three dots to pop up a menu, and select the Disconnect option (might be named differently in 1.4.76).
-
How do I add folders as Read Only, so if I edit the info in the destination it does not edit the NAS source.
If the NAS is the device that you want to have read-write access, then the simplest thing would be to set the folder up on the NAS first. From there, you will be able to get a read-only key to use on another device.
-
The weird thing is that this issue only appears for Read-only sync.
Managed to get Read Only and Encrypted peers out of sync in real Sync setups as well as in a lab setup.
When I had a read-only peer out of sync, the logs revealed that the peer was identifying a file as locally changed and therefore refusing to sync it. The workaround that has been reliable for me is to check the "Overwrite any changed files" option on read-only shares. Obviously this workaround is only usable where you don't want to keep local changes, as with a cloud replacement style node.
Of course, this doesn't explain the erroneous detection of a change on a peer that nobody touches...
-
Due to limited data upload rates, he needs to upload the same photo twice at the same time...
I don't understand this, but maybe I'm missing something.
The way I see it, the phone (or any peer) will only spend as long as it needs to get any new content shared with at least one peer. While the phone is busy doing that, all other peers will be sharing with each other. If we assume the phone's connection is the slowest, all other peers will be done as soon as the phone is done. Remember, Sync is full duplex, i.e. data flows in both directions at once on each peer.
-
That's a good point. I could setup keys that never expire and don't require confimation for each device and then store them in a safe place. That way I wouldn't have to go back to the devices if I needed to make changes on the server or off-site computer. One possible negative that I can think of is, wouldn't it require more time and bandwidth on the part of the device that is sending the photos to sync both the server and the off-site computer?
It seems to me that you're holding some misconceptions about how Sync works.
First of all, key expiry and confirmation are only relevant to the first use on an additional device. Once set up on a device, a key never expires, nor does it require further confirmation.
Second, the idea of having multiple devices using the same key is that they all exchange information with each other. If a key for your phone is shared with multiple other devices, it won't take any longer for the phone to deliver changes, because the other devices can communicate those changes among themselves.
It might be a good idea to start by reading all the articles under Getting Started With Sync and Common Questions at http://help.getsync.com/.
-
Thank you for the suggestion. I was trying to keep the setup simple, by having a single folder synced between the server and off-site computer. If I sink the individual folders, I will have to make two connections from every device that I want to sync (backup). Example one from the iphone to server and one from the iphone to off-site computer. As the number of devices grows or if something changes in the future, I can see this becoming complicated and time consuming to change.
Sync works with keys, so all you have to do is set up each key/folder combination on the server and the offsite computer. You don't have to tell the iPhone or either server anything specific about any other device, because they find each other using the keys.
-
Thank you for responding. I believe that I am limited to read only links for the iphone photos.
Is there a reason you don't want to share the individual folders with the off-site computer?
-
I would like to be able to sync (backup) my iphone pictures and laptop pictures to my server. I setup a separate E: drive on my server for the pictures. I would sync the iphone to E:\BTSYNC\IPHONE and the laptop to E:\BTSYNC\LAPTOP. I then want to sync (backup) the server folder E:\BTSYNC (and all the sub-folders) to an off-site computer. This presents a nested folder situation and I’m not sure how to get around it. Thank you for your help.
I think you can do nested folders if all the keys are read-write keys.
-
Is there a way to reset the server to a default password? What effect might that have on the other clients?
Yes, you have to start Sync using a config file. This won't affect other nodes - synchronization uses keys, not the gui password.
-
Am I missing something, or is there a different way to access the web UI, other than http://localhost:8888/GUI?
Make sure you're not actually using uppercase for the GUI part.
-
@trevellyan
MacOS stores some user-valuable information in xattrs - like, the fact that file is downloaded from internet or color-tags attached to files.
Sure, I'm just not really interested in syncing those attributes, but I'm sure some people find it useful and I'm glad Sync can do it.
-
I've run into problems with other transfer methods with lots of small files, so I usually bundle the data into a monolithic rar file.
Interesting. Mostly I sync lots of small files, and for those my LAN rates tend to hover around 1MB/s with Sync. When I sync large files, I easily get into double digit MB/s. Most of the time at least one peer is on WiFi (802.11n). They're all Macs except for the obligatory always-on Linux box. All settings are default except folder_rescan_interval and UPnP port mapping.
I'm comparing with other automatic synchronization applications, not direct transfer, FTP or similar. Most worked OK with large files, but they all bogged down when I hit them with thousands of small files all at once. Some were orders of magnitude slower than Sync in that scenario.
it seemed that the presence of other network traffic (Netflix, for example) would put BT Sync "off its game".
I would regard that as by design, Sync playing nicely with higher priority traffic. I believe the protocol is designed to do that. In fact, at one point I was limiting upstream bandwidth for fear of saturating my connection, but I stopped doing so and it never seems to be a problem. -
What seemed to be vital to getting speeds up: finding the right values for "recv_buf_size" and "send_buf_size". With the defaults (10/10), it kept settling at ~1 MB/s. So I tried 32/32, but the improvement was minimal. I then tried out 24/24, and the results were dramatic: I started getting 6-10 MB/s.
Are you syncing mostly large files, or mostly small files? The only time I see performance far below available bandwidth is with lots of small files, and it's still much better than every alternative I've tried.
-
How the heck do I view a list of connected peers for each synced folder without the webui?!
Maybe you can find what you're looking for using the API.
-
How do you use a text editor? Do I have one on my mac?
Yes, it's called TextEdit.
-
It does however seem to only be an issue with the node that I'm using the encrypted key with. Perhaps that is a known bug.
Yup - http://forum.bittorrent.com/topic/18036-extended-attributes/
Share With Unauthorized Peers
in Sync General Discussion
Posted
Anyone with a valid key for a folder can share that key with someone else and thus grant the same (or less) access they have to that other person. It's been this way since I began using Sync, which was late 1.2.x if I remember correctly.