RomanZ

@xesteve @FLIPNEUS @Peter1968 If you guys are willing to help us adopting Sync to work on ArmadaXP / Armada370 platforms for DSM6.0 out of the box - please PM me.

@goldsmit409 Sync should work fine in such setup, we had some users with very similar use cases. When transferring data, Sync splits it in smaller chunks (actual chunk size depends on file size and varies from 32Kb to 4Mb), also it is using uTP (a UDP-based) protocol, which is pretty robust for unstable connection. Sync can run headless pretty well - see this article for details. License can also be applied via command line as well, so you don't need an embedded license, just apply it via command line during setup process. The only issue I can see here is that Sync does not provide a confirmation of a kind "All files delivered". Using API you can find out that "there is nothing do download at the moment", which still doesn't means that everything was downloaded. This can be workarounded by placing text file in the synced foler with list of files to be delivered and their hashes, which can be checked by script on endpoint upon delivery.

@NotANumber Also, one of a new security features in DSM 6.0 is disabling of admin account if it is using empty password. Admin account is used to run Sync - so it is also good point to check it.

@NotANumber That's strange. The issue was only touching ARM based architectures, while DS1813+ is cedarview and x64 based. I wonder if Sync generated any dumps in /volume1/? Should be looking like "@btsync.core"? Please send us dumps and logs if any.

@all Unfortunately, submitting packages to official stores as well as adopting to new OS depends not only on Bittorrent, but also on Synology. Both are is rather slow procedures as it includes some internal Synology tests. You can download latest version of Sync for Synology here for manual install, although Sync MAY not start under DSM6 (it depends on your NAS model), as Syno has changed the policy towards ARM / ARMHF builds requirements in DSM6.

@Speednet Currently there are some issues reported by Synology QA regarding Sync. We are working to get it resolved.

@sbhouchen First of all - thanks for bringing it to attention. We've updated KB. This option is in megabytes, and this is size of maximum allowed buffer for arriving Sync's service data. Usually, one should not touch it. It can be increased in rare cases when this buffer is not enough - for example, if you got really huge amount of files in a single subfolder (like, 500K of files).

@fillmoreeast As there is no graceful shut down at the end of log, it looks like Sync has crashed. I suggest logging it to your NAS via SSH and checking /volume1/ for "@btsync.core" files (which are core dumps). It could also be in /usr/local/bittorrentsync/bin/btsync or /usr/local/bittorrentsync/var Send us dump for analysis and we'll know more about crash reason. BTW, which version of Sync do you use?

@NaCkHaYeD Settings look good. Disregardless to what UI says - does your NAS manage to hibernate its HDDs? If no - I can think of also disabling "enable_journaling" setting and writing "0" to debug.txt (you'll need to SSH to your NAS). Let me know if all these measures allow your HDD to sleep.

@Terence We usually post outcome on forum, though not sure if it is going to be useful for you as Vasco is using mixed environment of 2.2.5 and 1.4 clients. I can only advise to take care of hardware - syncing millions of files requires really lots of memory (count roughly 1.5kb per file/folder).

@moxou It is very likely we are aware of this crash. Fixed build is on the way, although to get 100% confirmation that this is your case also - we need crash report from your Mac. It should stay in "/Users/<user_name>/Library/Logs/DiagnosticReports/" and start with "BitTorrent Sync"

Vasco, Let's continue in our help desk.

@yhsvl Thank you for your feedback. We'll be happy to find out what happened. Could you please collect debug logs ASAP (if Sync is running they keep rotating and may kick out archiving event) and send to use? We need logs from both your computers. For ease of analysis let us know a file or two that were sent to archive. When sending logs, mention this forum topic so we can identify you.

Hi Vasco, I'll start with your questions: Logs and journals could be turned off by writing "0" to debug.txt and setting "enable_journaling" power option to "false". Though, I'd advise to keep it on for now as your setup has some issues. DB contains the tree of all files that you want to keep in Sync. It's size depends on 2 things: 1) amount of files and subfolders in synced folder 2) amount of operations you do with files. I suspect that you got something around 2.2M files inside synced folder. Is that true? What is the version of Sync you use on source? We had such possibility in 2.0, but as many users removed their files accidentally, we completely removed that feature from Sync 2.2 and newer. No worries, we are here to help. We'll do our best to deal with your issues. I'll ask you to send us some debugs below, the simplest way would be to open support ticket with us so me and my colleagues can work altogether on your issues. Mention this forum topic in message body. And now to your problems: There are 2 common things that can cause such behavior: a) permissions. Although, as you checked all permissions manually it is unlikely reason. b) ignored files. Sync ignores some files according to IgnoreList set of filters. I suggest checking if there is something that is ignored in your case. There is some issue that prevents Sync from transferring data, so it's not about your bandwidth. We need your debug logs to find out what happens. Your huge DB makes me thinking that you got enormous files tree which consumed all resources (both RAM and CPU) on your NAS, which results in inability to Sync. I also suspect lack of resources. Does the Sync UI opens fine in general? Quick workaround here is just to copy your link produced by Sync from NAS to any online QR code generator. Works fine.

Hi JW, By default all Sync HDD operations run on lowered priority so Sync won't interfere with all your other activities. Still I suggest checking the power option "hdd_low_priority", it should be true. Also, which version of Sync you use? I suggest upgrading to 2.3.5 if you use anything older: 2.3.5 contains some fixes related to redundant indexing.

@bsdll Windows gives service 30 seconds to save its data, so yes - it is graceful shutdown. Of course, stopping service will stop all synchronization.

@abramq In short: If you are not forwarding wide ranges of ports it is pretty much safe, the extra load is minimal. In details: "visibility" of forwarded ports depends on where it is forwarded to and usually is checked with TCP handshake sequence. Your router plays rather passive role here, i.e. if there is no one responses from the location where forwarding points to, no one will know that port is open. The handshake itself is very lightweight, so even if you'll get scanned all the time from internet (which is very unlikely), it won't throttle your connection. The main thing I would care about is to ensure that your PI has static IP and your DHCP server is aware of that. Otherwise, you may get your SSH port forwarded to some entity in your network that you may not want to expose.

@fefrie Sync on WinPhone only works within its sandbox. So when you Sync data to WP, it'll land inside Sync's sandbox and you either have to explicitly send if from Sync to other apps, or (if other app supports extensions) - pull out data from Sync sandbox with extension. Photos can be backed up from WP to other peers normally. Could you please elaborate - what do you mean under "download list"? Couple of screenshots could be great.

@bsdll Sync breaks all files into smaller pieces when syncing. If something is not finished when Sync was stopped, it will continue from the piece it stopped last time. The only peculiarity here is how you shut down Sync itself. If this is a graceful shutdown (like SIGTERM on POSIX systems) - all is fine and Sync will have a chance to save all the data. Ungraceful shutdown may lead to redundant re-syncing and DB corruption.

Sure, you are welcome. Let me know if it will work fine for you.

@abramq They are only removed from Sync, not deleted from HDD. All data stays intact. The main drawback here is that one has to re-add folders manually, taking key / link from other peers. It's about inconvenience, not about data loss. Yes, there is auto-update. Although, we push there only those builds we are highly confident in. Usually, when new build gets released, we provide it to website, forum and "Check now" button only.

Stephan, It is bug in way 2.3.0 ... 2.3.3 shuts down before upgrade. So it is tied to the version you update from, not the version you update to. Therefore it can't be addressed for people who already has 2.3.0 ... 2.3.3 installed. Only with backing up storage folder. As soon as you are on 2.3.4 or newer, issue should not popup ever.

@tjluoma In short: yes. It is safe for 2.3 and newer In details. Older versions (2.0.x IIRC) Sync could determine improper time when re-adding advanced folder. Currently, Sync just grabs the mtime when adding folder and determines which peer has newer version of a file. In your case that would be Desktop, so Desktop will start seeding changed files to your Laptop. Although there is one peculiarity which you should be aware of. Sometimes, users explicitly copy old files in synced folder. Such files has older mtime, so Sync just "remembers" the fact that user wanted to keep that file. This information is kept in DB. When you disconnect the folder, DB is wiped out and when re-adding folders, such old-timestamped files may be replaced with new ones if there are any other peers that keep newer version.

@lupus That's rather strange. Since 2.3 we are using very special API which allows us to detect the fact that file is busy without actually opening it (and, as a result, preventing Access or other apps from opening files for exclusive use). I'll send you instructions in PM on how to debug.

@kenneito All users should be able to edit their own posts. Sorry, wanted to leave a link to FileDelayConfig article so you can find it easily. For the FileDelayConfig - the file is pretty flexible. You can remove all the filters there, leaving simple "*" : 10 to force delay for all files. Just keep the JSON syntax so Sync can parse it.