sergey@bt
-
Posts
86 -
Joined
-
Last visited
-
Days Won
1
Posts posted by sergey@bt
-
-
Symlinks should be synced as links between POSIX systems. On Windows, Sync does not currently recognize any special files (everything treated as generic file).
-
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.
-
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.
-
Actually Sync already uses lstat() and symlinks should be synced as links (not as files). Do you see any different behavior?
-
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.
-
When invalid API key is used, Sync application will exit shortly after start. Sample code does not check this condition.
-
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.
-
With 1.1.48 getting a lot of these in the sync log:
[20130623 18:15:51.108] SyncDb: failed to execute query to save file info - 1
What is your operation system? Is it the only error you see?
-
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?
-
1.1.43 does not fully fix it. Please use http://syncapp.bittorrent.com/1.1.46/ if you see this issue. There was a race condition when working with config file which could cause adding the same folder twice.
-
Dantounet, can you please try new new build from here: http://syncapp.bittorrent.com/1.1.43/ ?
-
.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.
-
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).
-
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
-
Yes, files will be re-indexed. But indexing will start only when read-only machine will receive metadata (list of files) from other machine.
-
Database issues (if any) should not stop indexing. However indexing will be aborted if some error happens while enumerating files (e.g. if some folders are not accessible for Sync). If you enable debug log, you should see at what path it stops.
-
Could you please try this ARM build: http://syncapp.bittorrent.com/4test/btsync_arm.gz ?
I've added error codes to all DB related log messages.
-
Do you use config file or run Sync with default configuration? Do you use single UID/GID for btsync binary and files?
We saw such error on Android when sqlite was not able to find folder for temporary files. In Linux we set it to the same path where database itself is stored (storage_path in config file or .sync in current process folder by default).
-
We do use AES-128 in 1.1.x. Protocol has changed since version 1.0.x. AES-256 was removed from user guide PDF, but not from Technology section on site. We will update site shortly. You may find a lot of discussions AES-128 vs. AES-256 in Internet (including related keys attack). We believe AES-128 is not weak at all and it's a good choice for session encryption today. Also it's ~30-40% faster, which is critical for low end CPUs and mobile devices.
-
What platform do you use? Is it Linux specific? We added more logging into recent builds. It may be the reason why you started to see it in log.
-
ECB in the context of this Win32 API call means basic AES operation - encrypt input block with key. The real mode of operation depends on what is encrypted and how the result is used. Currently Sync uses counter mode. But we are still working intensively on a protocol, so it should not be considered as a final spec.
-
Latest Android build is available at: http://syncapp.bittorrent.com/1.1.33/BTSync-1.1.16.apk
Changes:
- Correctly handle disabled 'Use cellular data' option (previous version could send some traffic)
- Added 'Pause' for syncing folders
- Added backup of application settings
- Battery usage improvements
- Updated UI
- Various bug fixes
-
What Sync version did you use? Also please check .SyncTrash folder in your shared folder (it's hidden, you may need to enable option to view hidden files). Before overwriting file, Sync should save existing copy in SyncTrash.
-
What application did you use to create PDF?
[solved] 1.2.x slow as in the 90s when 1.1.81 is fast (Win 64bit)
in Sync General Discussion
Posted
Please try build 1.2.73. It should be fixed there.