kos13

I don't have any answer to the question at the moment. But we listen our users carefully and got your request. Keep in mind, that Sync is just 2 months old software, so not everything is defined yet.

What version of Sync you are running? We made a lot of fixes in this area in 1.1.15.

You mean it was working and now it is blocked?

What version of Sync you are using?

I tried it. Of course without Sync API usability is not straight forward and definitely not for an average user.

Matt, That means that there is a file that Sync can't accept, so indexing is stopped. It might be due to long name or special characters. You could turn debug logs and discover this file, or send logs to us and we will do this. Steps are here

What Sync version you have? Sync is not compatible between 1.0.x and 1.1.x versions. If you are on the same version, then most likely this is connectivity issue, which is much harder to solve. Since your boss firewall might have udp blocked.

Could you please try to remove .sync configuration folder and re-add your folders? We did change a lot internally so there might be some configuration left over. Sorry for troubles.

New build 1.1.15 is available.

We found issue with Linux version. Will release update tomorrow. Sorry for any troubles.

Have you adjusted rescan time?

Your issue is not solved. There is conceptual problem and we hadn't find any easy solution to it. Problem is that on Windows and Mac TEst and Test are exactly the same name. Naturally it seems that you just need to have a single file irrespective of the case. However if you will throw Linux into the game, TEst and Test are to different names. We will fix this issue, but still looking for a right solution from internal architecture and p2p concept.

We changed a way we store metadata, so yes it re-index everything. Sorry for any troubles it may cause and incompatibility with older versions.

I do have unfair advantage

Should be fixed in 1.1.12 build

Please see first message of this thread.

New build 1.1.12 is ready.

We are aware of this issue and it will be resolved in next builds.

Thank you for logs, we will analyze them and will get back to you.

This is definitely False Positive we will contact Kaspersky and Trend Micro on this matter. I'll keep updating this thread

First can you check that Sync.exe has a right BitTorrent signature? Could you please also send us a version of KIS you are using? There are two cases: 1. You downloaded infected binary; 2. Or this is a false positive from KIS and we will take care of it.

The next build will be just the first step in memory optimization. Usually for such kind of things you have to significantly change core, so this is why the build is delayed. However changes that we made will allow us much easier remove liner growth in future builds, but not in the next one. Keep in mind another thing, if there is no linear growth of memory - data will be stored on disk and that will mean higher CPU and slower operation. Which is desired behavior for NAS, but not for desktop.

Please let us know if the problem is resolved with MTU = 1500.

Coud you please PM me your email. We would like to discuss your use case and see what we can be done. But obviously Sync is pretty much the only way to effectively distribute Gb of data across thousands of people.

Lock/unlock is kind of complicated in p2p. Let me show you the problem. You want to add a new computer (#1) and approved it on computer (#2) while computer (#3) is down. Then #2 goes down, #3 is up. How #3 will learn that #1 is approved to join? The only way is to approve #1 on #3, but this would be a nightmare if you have more than two devices.