Disappointed Cat
-
Posts
299 -
Joined
-
Last visited
-
Days Won
5
Posts posted by Disappointed Cat
-
-
Out of curiosity: Is the data sent by RO nodes verified by an RW node?
This could be exploited. Especially if here are no RW nodes online.
-
New builds are coming sooner and sooner.
The read-only stickiness and the re-indexing after restart are indeed gone and I like the ergonomic GUI changes.
I also tested renaming large directories currently in sync which at first worked
but then I jumped at it and it broke again. I've sent logs your way.
-
I'd like the option to set a maximum number of versions for a file,
also a minimum time diff so we don't have a hundred versions in an hour, i.e. for a source file.
Storing versions in a compressed archive would also be great. Let's say on a per folder basis.
I'd consider this a viable alternative to delta versioning filesystems.
One more thing.
Since versioning is done peer by peer they should be synchronizable.Even better if the sending peer could save versions for itself too.
-
Most likely Office temp files.
-
Of course it is.
If all computers will have the same files when you add the share in BTSync, nothing will be transfered.
The timestamps should remain as is or metadata will be synced though.
-
It's IPv4 multicasting, somewhat similar to broadcasting. BTSync uses it to find peers on the local network.
-
All options should be settable by a per share basis.
What I mean is beyond the global advanced settings all shares should be able to have their own - overriding the default.
Also an option to disable live sync on heavy use shares and switch to periodic sync.
-
Like this: Preferably with a simple init script.
Start
su "www-data" -c "/path/to/btsync --config /path/to/config"Stop
killall -u "www-data" btsync -
Run btsync from the same user as owncloud.
Or you could use file ACLs.
-
TL;DR ^^ Many of us experienced indexing issues in the latest 1.1.27 version.
I've seen incomple sync reported as complete and a couple of deleted files were synced back.
I'm sure the developers will fix this in no time.
-
This is the official source for 1.1.27 binaries.
-
I have the same issue, especially with the droid client.
Until it's fixed all you can do is manually delete these files on the computers that were offline.
Also keep an eye on some files not being synced at all when the peers falsely report that they're synced.
-
There are still conflict issues, especially with android.
If files are changed while the android client is offline then when it comes online it will overwrite the new versions.
This happens pretty much 100% of the time.
Maybe it reports out-dated changes to the other peers before checking for remote changes?
The desktop version seems good-ish. Sometimes a few deleted git pack files get synced back, but no conflicts so far.
-
Anyone with root access to that system will also have access to your files, secrets and everything.
Also you have to trust the person setting up the shares or have direct access, i.e. SSH.
That's why so many of us are asking for encrypted read-only secrets/nodes.
-
Live long and prosper.
-
UDP for internet, TCP or UDP for LAN
Correct me if I'm wrong but it's more like UDP only or UDP and TCP for LAN.
The control channel is always UDP.
Is it correct that UNC-Paths are no longer supported?
It's forced by default from some versions earlier.
Go ahead and check the sync.dat file or the logs.
-
Indeed. They removed the link because this release is being rolled out by the auto update system.
Try here.
-
They found the source of this bug and it's fixed in the .27 version.
-
The same thing is happening with 1.1.26 and droid 1.1.7. I edited a file - now on a win8 client - which was propagated to the other peers just fine. Then the droid client on my MyAudio sent out the previous version as if it's the newest...
I also have sync running on a HTC Desire and it didn't have this issue.
The same read errors are present in all log files. This is madness.
-
First thought: Aw, man.. 4-6 hours of indexing again?
Then I see it's multi-threaded now,
but also painfully slow.CPU usage also seems fine considering it's re-indexing hundreds of GBs.
Can I ask why is it necessary though? What's changed in the indexing department?
-
-
Look for the settings.dat file in the .sync folder or wherever you're running BTSync from.
It's a bencoded file.
At first I too edited in my cert but then I switched to apache reverse proxy.
You're better of with a reverse proxy and you can even have your own authentication method.
-
Here's the next one...
Logs on the linux peer where the file was edited:
[20130602 02:17:30.273] ReadFile error: Gastro.cls.php:0:3134:3134:3
[20130602 02:17:31.238] 172.30.20.3:49072: did not pick any blocks. blocking peer temporarily
[20130602 02:17:31.419] Gastro.cls.php: Piece 0 completeLogs on Win8 where the file wasn't even opened (the local version of it):
[2013-07-02 02:13:37] ReadFile error: Gastro.cls.php:0:3134:3134:3
[2013-07-02 02:26:31] ReadFile error: Gastro.cls.php:0:3146:3146:3The win8 client's clock was ahead by 2-3 seconds. The automatic NTP sync doesn't always work in windows...
So I'm thinking that few second time diff could've caused this if there's a read error. BTW why are there random read errors?
I force triggered an NTP sync. We'll see... But something is definitely broken.
Update: Now two files at once. Same read errors then an overwrite.
Am I seriously the only one experiencing this?
-
They're not mini dumps though.
Let me know if you need more or something else.
.SyncIgnore
in Sync General Discussion
Posted
Just a side note: That way you'll end up with an empty 'subfoldername' directory.
If you want to exclude it entirely leave the /* suffix.