• Posts

  • Joined

  • Last visited

  • Days Won


About sergey@bt

Profile Information

  • Gender
    Not Telling

sergey@bt's Achievements

Advanced Member

Advanced Member (3/3)

  1. Symlinks should be synced as links between POSIX systems. On Windows, Sync does not currently recognize any special files (everything treated as generic file).
  2. Thanks for the logs. We found the issue. The low speed is caused by infinite indexing and high disk activity. It happens in some cases after upgrading read-only folder from 1.1 to 1.2. We will provide fixed build shortly. As a workaround, re-adding read-only folder should fix it.
  3. The reason why we switched to stdout in no-daemon mode is to be compatible with runsv and to allow log rotation. We didn't expect to break anything. Is there any easy way to redirect stdout to file in start-stop-daemon? If not, we will provide an option to force logging into file. Regarding debug.txt - it was changed long ago to check it on start only.
  4. Actually Sync already uses lstat() and symlinks should be synced as links (not as files). Do you see any different behavior?
  5. Secrets with support of encrypted peers have some performance penalty. On low-end CPUs (NAS or mobile devices), it may increase file indexing time by 2-3 times. This is the main reason why they are not enabled by default when generating new secret from UI. There should be no significant performance degradation on modern desktop CPUs with hardware AES support.
  6. When invalid API key is used, Sync application will exit shortly after start. Sample code does not check this condition.
  7. Do you use read-only or read-write secret for this folder? Do you see if other side wants to download the same amount as the first one wants to send? Also please enable debug log on both sides and check it for any errors.
  8. What is your operation system? Is it the only error you see?
  9. This log message means Sync is not able to verify signature (integrity) of a list of files from remote peer. Is this the only error you see in sync.log? Do you have Windows-PC and NAS on the same network (LAN)? Does it happen every 10 minutes or 10 seconds?
  10. 1.1.43 does not fully fix it. Please use if you see this issue. There was a race condition when working with config file which could cause adding the same folder twice.
  11. Dantounet, can you please try new new build from here: ?
  12. .sync is the default path for storing Sync data. It can be changed with storage_path parameter in config file. You need to create debug.txt file in your storage folder. If you put 0 in debug.txt, it will disable logging errors. If you put FFFF there, it will enable all debug logging.
  13. This message means Sync is not able to verify integrity of a file metadata received from remote peer. Enable debug log and you should be able to see version of remote peers in sync.log. If remote peer uses some old version, it needs to be updated to 1.1.42 and folder needs to be re-added (no need to remove files from disk, just re-add it in btsync UI).
  14. First of all, enable debug log on both ends. Then you should be able to check if your home server is trying to download anything from your office machine. Probably it's stuck at some particular file. Alternatively you may submit debug logs to us for analysis. Please follow instructions at