RomanZ

Administrators
 View Profile  See their activity

  • Posts

    3,588

  • Joined

  • Last visited

 Content Type 

Everything posted by RomanZ

  1. RomanZ
    @Tdeco Just in case if you do not want to share it publicly - you can mail us directly to syncapp@bittorrent.com (or, just submit a ticket to us at syncapp.zendesk.com).
  2. RomanZ
    @cpbotha This is a known issue and it happens due to bug - only when folder where you try to apply RO key is not empty. Will be fixed in future.
  3. RomanZ
    @fabio978 Looks like your DB got corrupt due to power loss. Did re-adding folder help? @onecentx Downgrade is not possible. 1.3 and 1.4 DBs are not compatible.
  4. RomanZ
    @scintilla13 The option was deprecated as Sync now always prefers TCP if possible. So consider it to be turned on all the time. If you are experiencing some troubles with syncing speed over LAN - I suggest opening support ticket for us and including profiler information.
  5. RomanZ
    @mdovey Unfortunately, there even more resources sync dependents on - which prevents NAS from sleeping. We are working now to fix it (hopefully - make a final fix). I apologize for inconvenience.
  6. RomanZ
    Possible workarounds: - Use RO link instead of key - Sync data to another, empty folder then move the files you want to be present there into this folder - Add a new folder, then update the key to RO one. See the topic above - they are mentioned there.
  7. RomanZ
    @sciurius I see your Key for the logs in our ticketing system submitted on Saturday, thank you for sharing. We have really big number of issues reported these days so it takes a while to analyze logs and respond to everyone. We'll look into your logs and do our best to determine the root cause. We appreciate your patience. @SchmitzKatze Yep, it only adds new content (otherwise, it would be too heavy too keep such big log in memory).
  8. RomanZ
    @scintilla13 The bug related to creating new key when you enter RO key for a folder with already existing files: 1) has a number of easy-to-achieve workarounds. 2) does not ruin any core functionality therefore considered not to be critical.
  9. RomanZ
    @dfluff The "out of sync" or "sending" status might appear when IgnoreList is different on different peers. It is a known issue and bound to the fact that trees of synced folders become different on different computers.
  10. RomanZ
    @SchmitzKatze The log piece is not enough. It already shows the results of a bug, not the bug itself. Though, what is the problem to catch it in the log? You can extend log to rather big size by setting "log_size" advanced preference to, say 1000 (~1Gb x 2 log size). And, of course, collecting before Sync is restarted.
  11. RomanZ
    @Laloeka It is not a bug. Nested folders (share in a share) are allowed only when both have RW access (it doesn't matter if you ignored folder in IgnoreList). The limitation is bound to Sync's internal architecture.
  12. RomanZ
    @hurik It is not fixed yet (and won't be in upcoming build), sorry. As issue is not critical - we'll fix it a bit later.
  13. RomanZ
    @chungyan5 It depends on your hardware. What is your laptop configuration? I'm especially interested in CPU, RAM space and HDD speed.
  14. RomanZ
    @nickviz What about the direct copy from A to B? What is the bandwidth of A<->B and what percentage of it utilized by Sync?
  15. RomanZ
    @Brilliantsam Issue confirmed, looks like a bug. We'll check how / when it can be addressed.
  16. RomanZ
    Hi all, The issue is not as simple to catch. It never reproduces in lab "on demand", has multiple root causes, so technically, it can be fixed several times. I would ask users who suffer the issue supply us with debug logs - so we'll try to find out what happens and fix it. Please send your logs to syncapp@bittorrent.com with reference to this topic and your scenario described.
  17. RomanZ
    @markymark77 As GreatMarko mentioned - the product status is Beta, so there are some issues happening to it. If you are willing to help us with your issues - we'll be happy to find out what happens to your Sync - and make it better. @ChrisH IIUC you say that people does not read docs that's why they are unaware of the fact Sync is beta. Fair enough (though not that good for people). I'll check how we can make it more clear.
  18. RomanZ
    Hi all, I wonder if anyone managed to collect core dump of a process? If yes - i'll be happy to get it to syncapp@bittorrent.com
  19. RomanZ
    @JohnCentaur I've opened a support ticket for you. Please follow our support instructions to resolve the issue.
  20. RomanZ
    @affinity Could you please elaborate - what exactly is not working in WebUI on your Debian? It might be a known issue and / or I may propose some workaround. @Tcll Note, that Sync 1.3 and earlier were never supported WinXP x64 officially (though, most likely were working with no issues). Only WinXP x86. As for the rest - see my previous post, BT is aware on people's feedback. @andrewb 1.4 release contains many changes. Though, as your NAS has glibc newer than 2.3 - the build for i386 should be working fine for you. We'll check what could cause this error and get back to you.
  21. RomanZ
    @cz2000 Okay then. I suspected that you were experiencing same issue many people suffered in China (inability to reach tracker server), but seems that you have something different. Could you please describe what exactly is not working?
  22. RomanZ
    @SamD The items 1-2 should work fine - C2 should restore backup to F2 on C1. Same for item #3. I only guess that issue might be in the way you suppressed the F1. Could you please elaborate? Did you run a new sync instance without F1? Or simply removed it? Or some other way?
  23. RomanZ
    @NipponBill I need your debug logs to find out what happens. Preferably from both peer-behind-proxy and other peer. @todorb Do I understand correctly that one peer stays behind NAT and another behind proxy? If yes - could you please try to forward ports explicitly on your NAT and see if it helps?
  24. RomanZ
    @afelicio It looks to be a peculiarity of how AutoCAD works with files. It simply keeps it open and restricts any access to it. If Sync can't access file - obviously, it can't sync it. I can only advise to check AutoCAD preferences to see if it can be not as greedy towards it drawings.
  25. RomanZ
    @brookman When file is moved to SyncArchive it means that some other peer sent deletion message. What history says? Does it indicates which peer deleted files? Also - do you have the debug log capturing the deletion event so I can take a look at it?