umputun

I see some inconsistency in setting timestamp. After directory's sync it sets the current (local time on dest. box) timestamp. Not sure if this is expected behavior, but for regular files it sets correct (source) timestamp. This is on source box: 16777223 11980044 drwxr-xr-x 3 umputun staff 0 102 "Jun 19 13:36:10 2013" "Jun 14 07:08:14 2013" "Jun 19 13:26:48 2013" "Jun 14 07:08:14 2013" 4096 0 0 BitTorrent Sync.app and this is after sync, on destination box: 16777218 7688292 drwxr-xr-- 3 umputun staff 0 102 "Jun 19 13:33:13 2013" "Jun 19 13:27:02 2013" "Jun 19 13:27:02 2013" "Apr 30 03:13:20 2013" 4096 0 0 BitTorrent Sync.app

I have tried to test my theory about Another factor making my case a little unusual - some of directories shared read-only to many remote "guests". After upgrade to 1.1 I don't see them interacting with my computers anymore because they on 1.0 and protocols incompatible. So, maybe such communication between incompatible versions causing high CPU? It seems to be the case! As soon as I removed those read-only shares accessible publicly, the 100% cpu bug disappeared completely.

Sent

After upgrade to v1.1 (on 1.1.15 now) I see very long bursts with 100% cpu utilization on all of my macs. By 100% I mean 100% of one of cores. It stays in 100% for 10-20minutes, sometimes even longer. Then it goes down to low numbers for very short time (1-2mins) and jump back to 100. Such problem makes my old dual-core imac very slow and on mbp i7 eating all the battery in one hour. Nothing changed with my folders/files, this is the same ~80G total. The only new thing is upgrade from 1.0 to 1.1 Another factor making my case a little unusual - some of directories shared read-only to many remote "guests". After upgrade to 1.1 I don't see them interacting with my computers anymore because they on 1.0 and protocols incompatible. So, maybe such communication between incompatible versions causing high CPU? P.S. I have reported the issue via "Send Feedback" with sampling and debug info, but this time I didn't even get automatic response back. Not sure if my reports were delivered or not.

Ping. Happy to test on iOS (iphone + ipad mini)

sent, see #680

Thx, fixed.

oops, I have an extra '0' in title. This is about 1.0.130. Not sure if and how I can edit this title.

Hi, After updating on all my Macs to 1.0.130 I have noticed a couple of new issues, compared to 1.0.116: 1. Constant and high CPU utilization on all my macs. Even if sync paused it uses around 20-40% of CPU on every mac I have around here (from core2duo to i7) 2. Sync to read-only clients is very slow in some cases. Not sure if this is due slow transfer or slow detection of updated files, but some clients reported 8-12 hours delay from the moment I populate a new file. With 1.0.116 it was almost instant. Could be due a mix of version, maybe those clients run on 1.0.116, no sure.

if you running v. 116 you probably hit the issue I have described in http://forum.bittorr...ete-file-issue/

I'm trying to setup safe, local-net-only sync in my LAN, as safe as possible. I don't want it to transfer anything to/via WAN in any case, so from what I see I should do: 1. Uncheck "Use relay", "Use tracker" and "Search DHT" 2. Check Search LAN 3. Block in/out UDP (except LAN) for the "Listening port" Anything else? Probably adding all hosts to "Use predefined hosts" and uncheck "Search LAN" will also help to my paranoia, not sure.

and probably - 8. restore 1.0.130 Thx for this workaround, tested locally and worked globally just fine. It has one not-so-clear consequence - directory was deleted with all bad files as I wanted, but I can't recreate the same directory anymore because it get reverted to deleted state every time. Not a big deal for me, but something to keep in mind. thx again

Thx for idea. Unfortunately this can be too destructive in my case, because I have hundreds read-only clients. Probably I can assign the same secret, but I'm afraid removing/adding will cause redownloading of all files (20-30G). I'll try to experiment with this locally and if my fear not confirmed - will follow this route.

installed today officially announced 1.0.130 It has a promising item for me "Changed local date mechanism to avoid sync conflicts". It's hard to say if this release fixed creation of wrongly-touched files, but for sure it didn't solve the issue with such files created before. Right now I have 3 files with timestamp around Apr 2014 in btsync directory and I don't see any way to get rid of those files or edit. This is what I have tried so far (all my fill-access boxes on 1.0.130, read-only - no clue) 1. Just delete or edit at the time of btsync running - reverted to 2014 version 2. stop btsync on all full-access computer and delete on every computer. As I start btsync it reverted to those 2014 files 3. Set computer clock to 2015 and try to delete/edit - reverted again So, I need solution for this situation or at least workaround. Any bright ideas?

I have similar transfer speed with my RPi sync (max 2M/s, average 1.5 M/s). However I don't think it has anything to do with WAN speed (i have 50/10M line) but with performance restriction of RPi itself. As far as I see, at the time of ~2M sync RPi's CPU jumps to almost 100%. Another thing slowing down such sync - RPi by design sharing USB "connection" between LAN adapter and external drives.

As I removed a big directory (~20k files) from sync on RPi and kept just other small dirs with total ~1000 files CPU utilization improved dramatically. It has spikes at the time of transfer (up to 70-80%) but in idle it's not running 90% all time as it was before but keeps it in 10-15% range. Looks like monitoring for so many files makes poor RPi overwhelmed. I hope devs will able to figure out some way to improve it, because the idea of having RPi synced (in my case for backup) sounds pretty cool and useful.

Good news. Probably in my case a lot of remote read-only clients on 1.0.116 won't allow to delete.

Which part of the problem fixed? As I see files from the future act exactly the same (untouchable). Is there a list of changes for 1.0.125 somewhere ?

Well, I also can wait till Aug 23, 2014 and problem will resolve itself But this is the second case I have been observing for last 3 days and I don't think the question "how to delete such file" is critical here. The real problem to be resolved by devs - how to prevent such behavior of btsync.

You can't delete such file without stopping sync on all clients. I think it is. The only program touched this file except my text editor was btsync. I think there is a bug in btsync causing incorrect timestamp to be assigned to some random files.

File in question is not podcast.rss but rssproxy.py and readme. $stat rssproxy.py 16777223 9381841 -rwxr-xr-- 1 umputun staff 0 1149 "Apr 29 12:56:51 2013" "Aug 23 09:20:59 2014" "Apr 29 12:56:10 2013" "Apr 26 16:28:44 2013" 4096 8 0 rssproxy.py Not sure I understand what you suggest. I have already tried to modify this file but it got reversed by btsync. Probably if I touch it with timestamp > 1408842928 I will able to update and then delete.

I have similar problem - RPi constantly around 90-97% cpu.

Just got another case. Somehow btsync thinks timestamp is 1408842928 (2014/08/23 14:22:44.000 GMT) and reverts back all my updates for these two file every time I try to touch it. All full-access boxes have correct clock.

Today I have found somebody else's file in my read-only shared directory. I'm testing BTSync for multimedia distribution and have a few hundreds (probably) users with read-only secret. All of them got this file and asking me WTF kind of questions Getting such file is extremely scary thing. First - it can potentially lead to malware delivered to all of my users, and second - if I got file from somebody by accident/mistake/collision it means - somebody else can get one of mine private files the same way!

And if this file some sort of editable document/text - you will quietly loose all changes you made, which is in my opinion, the worst thing any sync system can do Probably those changes can be found in trash subdirectory, but still very bad behavior anyway.