[Linux: Can't Add Non-Empty Folder With Existing (Read Only) Key]

Still existing issue on 1.4.93 ?

[Latest Desktop Build 1.4.93]

Why report the size if you don't know how to calculate it then?

Sent from my SCH-S738C using Tapatalk

 

Wrong folder size matters.

If you are syncing 100 GBytes data but BTsync reports only 10 GBytes you should check debug log to find what "improperly" named file is stopping your folder indexing ....

 

Question to developers:

Why base code on ASCII when we are on Unicode era since decades?

[Linux: Can't Add Non-Empty Folder With Existing (Read Only) Key]

Workarounds observations:

 

1) Using a link (instead of key) is not possible if "file source" is a 2003 server or XP  cause limited to 1.3 (is it right?).

2) I will try it

3) I just tried to update the key but doesn't work. The read only key is not accepted.

 

this is the link to last 1.3 versions

 

http://syncapp.bittorrent.com/1.3.109/

 

maybe it could be useful to someone reading this thread.

[Linux: Can't Add Non-Empty Folder With Existing (Read Only) Key]

please, go deeper, about point 1, or suggest a link about it.

 

Thanks

[What limits speed?]

Since "lan_use_tcp" option was deprecated, I was no more able to take advantage of LAN speed sync

[Linux: Can't Add Non-Empty Folder With Existing (Read Only) Key]

Why should be considered a non critical issue????

 

BTSync is better than dropbox or similar because no space limit.

But local connection limits are present.

 

When I have to start a remote sync, most of the time I do a local copy (at local speed...)  on a portable device.

Then I will start to sync without waiting AGES ....

 

If is impossible to start a sync on an existing folder where I could download an older version?

[What limits speed?]

If your devices are on the same LAN, you could also try setting "lan_encrypt_data" to "false" and "lan_use_tcp" to "true". This can potentially increase the speed of sync on low-end devices due to lower use of CPU

Also, check that "rate_limit_local_peers" is set to false

(You'll need to restart BitTorrent Sync for these advanced pref changes to take affect)

 

This worked for me today without restarting BitTorrent. Now it can take advantage of 100Mbps LAN instead then 2 Mbps previous usage. Now I'm joking a little: to optimize bandwidth usage, next file processing and buffering should be prepared by a background thread ...

Fantastic Work .. in many applications dropbox has no more reasons to exists...