coewar

I'm not trying to argue but trying to understand better. As far as my situation, increasing the time is good enough for now. There still seems to be some gap I'm not making here though. If nothing changes on the RW peer, but does change on the RO peer, currently what would happen? Does the change done on the RO peer get essentially "undone" at the next re-scan, assuming no change was done on the RW peer?

Well, it would know simply because it receives notification from the remote instance of Sync on another computer. If you are syncing with the RO option (and especially with Overwrite enabled) then the only thing Sync needs to watch for is changes reported by the source which would be the other computer. When that other computer's Sync tells this Sync that something change, that's when it writes and downloads. So when it receives notification from the remote Sync that files X, Y, and Z have had changes, then it can locally scan just those files, without having to routinely scan them. Hence, it would not need to re-scan the entire directory, and it would only need to scan anything when it gets updates from another Sync instance. Am I missing something still?

@Helen, Why would sync need to scan anything if the share is RO, *and* the option to overwrite files is on?

OK.. so I see there are some challenges knowing if things changed.. however in my case the folder is a READ-ONLY one. So that means that Sync has no need to scan anything at all. It should just act when it receives updates from other instances. Surely that change can be worked on separately.

And it's done. So I guess the problem is that it keeps re-indexing. Why does it need to do this? Is that a bug that wasn't there before? It's kind of a problem because it's a large directory so it pegs the CPU for a while doing this. This is a READ-ONLY sync folder and I have marked it so that it should overwrite all changed files. So even if there is a need to re-index, there should not be for a READ-ONLY folder because the only changes it would have to sync is something from the other sync source. And that other source is actually offline right now. I have it configured so the source server has its sync service turn on for a few hours overnight. This way I can keep a daily snapshot of our data and have it consistent throughout the day, while also not interrupting the source server.

And it's indexing again! No files are changing during this time.

and it's done indexing.

oh my gosh! it's indexing AGAIN! Maybe that's what's going on. I didn't do anything.. no files were synced and I didn't restart it.

You know.. I had just started the service again.. and it indexed in just a few minutes. The initial time it took so long was after it finished syncing... so I wonder if that's related. I'll keep this topic updated.

Hi.. I noticed a couple of things: Service installed on Win2008R2 #1 - the web UI does not open any explorer or anything for the actual folder.. it looks like you intended for it to do that. This has not been working for a few versions now. #2 - I had I think 2.2 maybe? just before the name switch. But after I applied 2.3.8 it's really busy indexing the files and I left it on over 1-2 days and it was still doing it.. CPU usage very high during that time. Previously it was not like this for the same folder. The folder has about 48K files, running about 46GB.

I see. I did set that. And so far it has not corrected itself. I'm going to try to delete the files in question on the receiving side to see if it'll re-send.

Hi. I have a server that I created a READONLY folder on. Then on another server or computer I am syncing using that READONLY key. It seems that if I edit data on the other computer, those files no longer get updated from the master. It seems like this is a missing option in the READONLY mode; whether it should always force (like a mirror) on the target instances, or if it is to allow the target instances to not get their data wiped away... ? The purpose is.. I have a production database that I create a snapshot of.. I actually do it nightly by starting and stopping the btsync service at night for an hour. Then on my other computer I can test all I want.. and the next day I'll have it wiped out with an update from prod again. That is not happening though.

Gotcha. Thanks.

I don't understand has been going on with BTSync Windows app permissions. Back even with ver 1.3 I had difficulties, and now they just are worse with the latest ver of 2.x. I have PC's with an admin account and also a non-admin. I want different folders synced for them.. it has been working fine in 1.3 but I finally thought to try 2. I can't get the thing to run at all without prompting me for an admin PW.. to which I cancel anyway because I want it to run as the restricted user.. and the funny thing is that it then runs that way, but always causes Windows 7 to prompt me. I manually copied the BTSync.exe to the %appdata% folder, changed its ownership.. going to look at what else I can do.. but why does this only happen to BTSync? What is it about this one that causes these permissions problems?? And I have UAC turned OFF! oh... I just figured out a way. I created a Shortcut to the BTSync.exe and pass the /NOINSTALL option and it works.. without prompting! at first I had /BRINGTOFRONT option as I saw it running on my other user.. but I don't want the screen to popup everytime and so of course removing /BRINGTOFRONT seems to not matter and it STILL COMES UP when it starts. But I can live with that one,. oh.. figured that out too.. with the /MINIMIZED option... so why does BTSync LIE about the options? /NOINSTALL and /MINIMIZED aren't even listed. And it seems there is no consistency. I installed this 6 times on different users on Win 7 and 1 on Win 2008 and they are run with different command line options. All today, all with the latest version. BitTorrent Sync 2.2.5 (130)Usage: BTSync.exe [ options ... ]Options: /HELP Print this message /CONFIG <path> Use a configuration file /STORAGE <path> Storage path for identity and license /IDENTITY <user name> Creates user identity /LICENSE <path> Apply owner license /WEBUI Run webui

The BitTorrent stuff and Sync has been fantastic. And from the outside we don't know who's responsible for these decisions. And thank God some of us have started other projects to compete which is what drives to improvements. But the lesson I hope is learned is that you can't release something with such a crutch with the disclaimer that "we'll remove it later". More time should have been taken to release without the crutch. For one thing, you certainly lose credibility and trust from users who never wanted to be crippled.