umputun

Members
  • Content Count

    30
  • Joined

  • Last visited

About umputun

  • Rank
    Advanced Member
  1. 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
  2. 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.
  3. 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.
  4. Ping. Happy to test on iOS (iphone + ipad mini)
  5. oops, I have an extra '0' in title. This is about 1.0.130. Not sure if and how I can edit this title.
  6. 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.
  7. if you running v. 116 you probably hit the issue I have described in http://forum.bittorr...ete-file-issue/
  8. 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.
  9. 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
  10. 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.
  11. 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?
  12. 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.