necula@cs.berkeley.edu

I am a new user of BTSync, and I have not considered the use cases you mention (r/o copies and "Restore Modified Files"). Is there somewhere an explanation of what can the user expect in the various situations that may come up? I think that having separate ignore files with different semantics might be fine. I think there should be a way to declare globally that certain files are not included in the share, for both r/w and r/o nodes. Those are local files. I am willing to help formulate a solution that works for all or almost all use cases, but I feel that I should start by reading about the uses cases. Thanks, George.

These changes are with full-access secret. I did notice that if I add an executable file to one of the replicas, then the file is created on the other replicas as executable, but if I add the execute permissions to a file after it was added, this does not get propagated. In fact, if I then make changes to the file, the execute permission bit is unset when changes are brought in from other replicas. This is a bug in the synchronization of the execute permissions. Thanks, George.

Where is the latest documentation for how .SyncIgnore works ? I have discovered (the hard way) that this file can only be at the root of the share. I have tried to make it a symlink to a SyncIgnore file that is synchronized, but the symlink is rewritten. And I am having trouble figuring out how to name a file in a given subdirectory that is not root. I also do not understand what is meant by the sentence in the FAQ: ".SyncIgnore ... will not work with the files that have already been synced." Does this mean that if I add a file to .SyncIgnore after it has been synced the file will continue to be synced? I do think that this file (or something like it) should be synchronized between replicas. You want to be able to declare globally what is the intended content of the share. Thanks, George.

I noticed that btsync will try to move files with the correct file permissions (i.e., executable files with the execute flag set). But if I then change the permissions in one of the replicas, the change is not reflected in the other replicas. Is this intentional ? Thanks, George.

I have done some experimentation (on Mac OS X) and it seems that the .SyncIgnore file is not being sync-ed. I think that this is counter-intuitive and I am not sure what the full implications are. If machine A has a .syncignore, and I setup a sync with machine B, the latter will not get the .syncignore but will get all the files except those mentioned by the .syncignore. If the ignored file is created on B (say it is an automatically generated IDE configuration file that I do not want to sync), will it try to send it to A ? What if I now share the same share with a machine C. Will B and C send to eachother the files that A would ignore? I think that the semantics of .syncignore should be global, just like the share has a global semantics. All replicas have to be identical module the files in .syncignore. Thanks, George.