RomanZ

@Moe Identified and fixed. Please expect fix in next update. @zbigb69 Build go to the forum first - and after some time pushed to auto-update if considered to be stable stable enough. Therefore we always appreciate our community feedback on fresh builds.

@tmanz 1. Right. No automatic folder propagation. 2. Incorrect. You can still connect folders, though you need to do it by copying and pasting link. 3. Connectivity is not affected by Free / Pro functionality. Should be working as before.

@Moe Actually, it does - try to make an intentional mistake in your JSON and it will show you the error in console. Although, for some cases (like with EULA) it does not work for some reason.

@Moe You are welcome. Yeah, I understand that agree_to_EULA would be more logical if it is boolean, but we want to make it as explicit as possible. What is really wrong here, is that once you don't put it in the config - Sync gives no hint what happens. This looks to be an issue.

@wqlxx Yes. Your every product installation requires workstation license - if it is a workstation. If it is a server installation (like Win Server 2003...2016, etc.) - you need a server license.

@Moe Looks to be an issue - we are looking into it. Thanks for reporting!

@Moe Try strarting it with --nodaemon switch - Sync won't fork from current terminal session and will dump all output to your console, it might give a hint on what happens.

@rdej47 Can you please also try to share Classic folders (shift-click the "Add folder" button) between your Mac and NAS? Classic folders are more lightweight and may introduce better performance. Let me know if it helps.

Hi Marcelo, I can see that you've opened a ticket with our support system - we'll do our best to help you to restore file and understand what happened. Roman.

@xmy Unfortunately, it is not possible for iOS devices. The only option for camera roll is backup. It is possible for Android devices, all you need to do is to add a folder on your PC, then share it to Android and point it to the folder where pics are stored. The main advantage of 2.0 folder is ability to manage permissions. This is achieved by using extensively x.509 certificates to control who is allowed to do what. As backup folders are usually done between user's own devices (not with some other people), there is no need to enforce permissions control and Sync instead can save some power by avoiding some extra calculations and use more lightweight classic folders.

@Moe You have to add a new folder using encrypted secret. Try calling /api/v2/secretwith POST method and send {"type":1}as message body. Sync will create a set of Encrypted secrets for you. Now add a new folder using /api/v2/foldersPOST method and pass the secret you get as a parameter.

Hi Michael, Take a look into this article, it describes on how to sync folder to folder - you simply need to edit path manually when you add the link.

@karma007 Just grab the ARM binary.

Dear community, Sync 2.1.3 is now available. You can get it via official download site or using direct links below. Build is not yet pushed to auto-update. Direct Download Links: Installer for Windows: x86 installer x64 installerPackage for OS X: OS X packageGzip archive for Linux: ARM i386 x64 glibc23_i386 glibc23_x64Gzip archive for FreeBSD: i386 x64A list of what's new, improved, changed, and fixed in this version is available in the change log. Latest Android build is now also available via direct link: 2.1.0 APK

@patoka In short: yes. If second PC has Archive enabled, it will archive file when it gets deletion message from your 9-year-old laptop.

@Bletotum This is very likely because when file is created, it actually is still locked by app that created it. In former versions of Sync it gave 10 seconds prior syncing file, while now it attempts right away and increases delay every time it fails. We are planning to make some changes to address it. Keep an eye on change log for configurable delays in future releases.

@EricM Nothing special about these entries. Unfortunately logs do not contains info we are looking for. We still try to repro it in our lab, to see live how it happens. BTW, can you share the huge file in archive and outside of archive that are different? If yes - I'll send you a special location for uploading big files.

@EricM Windows API behavior is sometimes inconsistent towards junctions. Of course, we'll see if it is possible to make a full scale support in future. If no, we'll take care to deliver proper message to the user. Although, for now we can only warn user with an article in our Help Center.

@hungarianhc There are 2 ways to share files to other apps in latest Sync version. 1) Legacy way, "Open in...". When you do it, the file is copied from Sync to other app and there it can be edited. To get changes back to Sync (and to other peers) you have to "Open in..." from the app that made changes to file and send back to Sync. Not that convenient, though it exists for pretty long time. 2) Using extensions. This is new technology that was introduced in latest release (and actually, not that long ago allowed by Apple). Using extension allows you to open files that reside in Sync's jail in another app without actually copying them. So, in your test you used way #1. I wonder, if you can try to use #2, but using Sync + some other file (like, .txt) with some other app (like, Documents).

@EricM We are trying to reproduce issue in our Lab. I'll keep you updated. Could you please also get the .log, .log.old, .journal files from both Machine 2 and Machine 3 and send it to me? It may reveal what happened in your environment. Also, do I understand correctly, that the data you Sync is not being used by any app at the moment?

@hungarianhc Thanks a lot for detailed explanation! Step 6: it is by design. File needs to be local to get opened by other app. The main benefit of extensions is that now you can open it in another app, edit and save without copying it to another app's jail. Unfortunately, the issue you describe does not reproduce in our Lab. On step 8, it gives a second or two delay and actually opens the document in Numbers. I'd like to ask you to do a couple of simple tests: 1) try to do the same but with a different file (say, .txt) and different app (say, "Documents"). Does it open the .txt file with no issues from Sync? I wonder if this is something between numbers and Sync or this is purely Sync issue. 2) try to locate same file in Sync and "Open in..." it in Numbers. I wonder if it works well in your env. Thanks!

@EricM Yeah, junctions and links are not supported on Windows. Thanks for the feedback - we'll update KB with the relevant information.

@jrox10 The latest version now is 2.1.2, it contains some fresh fixes related to speed. It's worth to try it. If it does not help - then I'll need debug logs and speed profile from both your Win 2003 server and Mac. BTW, what is the exact version of your 1.4 installation?

@richeyyy These are temp files where Sync receives the data before renaming them to real files. Although, !sync is related only to 1.4 and older Sync versions, it was replaced with .bts starting from 2.0

@EricM Is it related to issues with junctions you mentioned in other thread or you did pure robocopy and sync to the same (real) folder and files were moved to archive?