stanha

The issue: Consider the situation where there are several master nodes. One of them, for whatever reason, decides to modify some subfolder name. What happens in this case? I would like to understand this issue better in the context of events. When the master r/w node completely syncs with another r/w node, and that other r/w node goes off line, and, meanwhile, the master r/w node renames some folder and could have taken more steps, such as file deletion or modification, then the logic would get really complicated in a hurry. If wish there would be a design document about BTSync somewhere where it explains all its logic. Because it can get really complex and the effects could be drastic if you don't understand exactly the rules of behavior. Again, I do not know the rules of behavior and how the events are stored in the database and processed when some other nodes come back on line. But what I am seeing here is that I have a duplicate of a pretty large folder with videos which at some point was renamed. By whom and at what exact time I can not possibly remember. And the only way to stop that old folder from appearing on the reference master node was to include it in .SyncIgnore. Again, if you, guys, would consider releasing the detailed rules of behavior, that would certainly help. I am kind of concerned about covering some issues in the detailed manual being written, not knowing if my understanding of it is correct or not. About the last thing I'd like to see is people getting the wrong picture of how it works in detail just because I do not quite see how it works. And my sense is that the issue of detailed description of logic is not going to go away, but would keep creating more and more misery in people because they do not realize what exact thing or action brings about what results. Anyway, thanks for your information.

Well, two way sync in the general public applications may turn into a disaster if some r/w nodes are operated by the people who do not quite understand all the nasty details that may arise, or if some "bad" guy wants to sabotage the system and starts doing all sorts of crazy things to raise havoc on this share. Secondly, one way sync is preferable in the situation where there is a reference version of the information not to be modified by anybody, no matter what. So, the two way sync is preferable ONLY in the situation where you know exactly who is who and what is what and are certain that no one will attempt to do some harm to the information or "screws up" things inadvertently. The "bottom line" is: For general public applications, two way sync is an invitation to disaster, which will happen inevitably, sooner or later. It is just a question of time...

"Fighting" r/w nodes and magical appearance of duplicate files/folders There is an interesting case of r/w nodes "fighting" with each other (in case you have multiple r/w nodes on some share). If you delete some files or folders on one r/w node, it won't help anything if you have multiple r/w nodes. Even deleting it locally, will not prevent it from being re-downloaded again in few seconds from other master nodes if they are on line, and even worse, if you are the only r/w node on line and delete some file or subfolder and verify that it all worked fine, you may not realize that it was nothing more than illusion. The same thing happens if you rename some file or subfolder, with even more amusing effects. Because it still exists on other master (r/w) nodes. As soon as they come on line, you will get your deleted or old versions of renamed files or folders downloaded from them again. Remember, all the fully synced r/w nodes contain the aggregate collection that is created as a result of UNION operation. Those files or folders that are absent on some nodes will be sent to them by the nodes that have them. And even more interesting behavior is observed if you rename some subfolder. What happens if it was already uploaded to other r/w nodes is that now you have two different folders with the same contents, the one with old directory name on other r/w nodes, and the other, with new file name on your node, and, since your new folder contains the same exact files as the old one, then it will immediately start uploading that folder to other r/w nodes as a new folder, and the other r/w nodes will send you a copy of the folder with OLD file name. Once the sync process for these folders is complete, ALL the r/w nodes will have two copies of the same folder with the exact same contents, but with two different folder names. And, even more interesting, once you notice that you have 2 copies of the same folder contents but with different name on your share, you may try to delete the folder with the name you do not like, not even suspecting that it came from other r/w nodes and wondering about where did it come from. But it will be all in vain if other nodes have that folder. They will simply resend it to you again. So, you MUST use .SyncIgnore if you decide to delete or rename some files/folders in case you have multiple r/w nodes, and some of them have already synced with those folders/files that you have deleted or renamed. Furthermore, all other nodes must also have them in their own .SyncIgnore file, and they may not even suspect that they have some duplicate files/folders as a result of actions on other r/w nodes. So, before deleting or renaming some files or folders, first, enter their names in the .SyncIgnore file and save it, and only then you can delete or rename them. Using .SyncIgnore Master file In order to prevent some unusual or strange effects arising as a result of deleting or renaming some files or folders (see: "Fighting" r/w nodes and magical appearance of duplicate files/folders), what you can do is to create the .SyncIgnore.Master file on one of r/w nodes. Also, in order for all the nodes to be in a consistent state and contain the same exact information as all other nodes, in case some files or subfolders are excluded from syncing for all sorts of reason, such as containing the private information, or scratch pad files, not meant to be propagated to other nodes, ALL the nodes need to have the same .SyncIgnore file contents. Otherwise, some of them will be updated with unwanted files and will propagate them to other nodes. Note: .SyncIgnore file does not propagate between the nodes automatically. Because it is an O/S dependent file and Window's version of it won't work with Linux and vice versa because of difference in file naming conventions. But the .SyncIgnore.Master WILL be automatically updated and propagated, just like any other file, if ANY r/w node modified it or extended it. The beauty of this approach is that nobody can dictate to your node which files you do or do not want to update and propagate, as it would be the case if .SyncIgnore was automatically propagated. Because that would be imposing someone else's opinion on what you do or do not want to carry on your node, which does not make sense and is not a "democratic" approach. The only thing to be kept in mind is that it is an O/S dependent file and so on Linux, all the backslashes ("\") in the file names have to be replaced by the forward slashes ("/") and all the blanks in file or directory names have to be replaces with "\ " to follow the Linux convention. What it means is that all the nodes can be automatically informed about the master nodes' "latest and greatest" .SyncIgnore contents via .SyncIgnore.Master file. So, they can simply copy/paste its contents into .SyncIgnore file and do some editing for the Linux version of it in order to comply with the O/S file naming convention. This should work great and prevent all sorts of files or subfolders being distributed unnecessarily. Furthermore, all the discussions and arguments about whether to automatically propagate the .SyncIgnore simply resolve without a single effort of the part of BTSync development efforts and everything "works as is". And even more important for general public distribution, where one node has no idea about the other nodes and where the information may be updated dynamically, at any point, there might be some changes desired to the .SyncIgnore file. But how do people know about the "latest and greatest" unless the .SyncIgnore is automatically propagated from the master nodes? And if it IS automatically propagated, then the latest master version of it may "step" on your local changes that correspond to your personal view on what to carry and what not on your node.

This topic has to do with the situation when there are multiple master (r/w) nodes and some of them do things to their subfolders or files that do not reconcile with other master nodes. The r/o nodes' logic is quite complex. But we have addressed it already and so far, there has been no arguments or objections to it for whatever reason. But the master node logic is even more complex and its effects are more far reaching. Consider the situation where there are several master nodes. One of them, for whatever reason, decides to modify some subfolder name. What happens? Well, what happens, whether he realized it or not, but he created a new subfolder, and it MUST be propagated, including to the master nodes. And even worse than that, the old folder that he thought he renamed, will still be redownloaded to his node from the other nodes. And his newly named folder will be propagated to all other nodes, r/w and r/o. Thus, everyone gets 2 differently named folders with the same contents. According to current logic, the reference collection is the union of all the master node collections. That is, if one master node does NOT have some files that some other master node does, then it downloads these files, so the resulting collection becomes bigger. The only way one master may prevent downloading and propagating a folder with duplicate contents (if other master node made a mistake and renamed some folder) is for the master node to place that folder name into its .SyncIngnore file. But that does not prevent all other master nodes from getting a duplicate copy of that folder. So, currently, there is no way for the master node to tell the other master nodes that some folder is a duplicate. There is an interesting case of r/w nodes "fighting". If you delete some files or folders on one r/w node, it won't help anything if you have multiple r/w nodes. Even deleting it locally, will not prevent it from being re-downloaded again in few seconds. Because it still exists on other master nodes. As soon as they come on line, you will get your deleted stuff downloaded from them again. So, you MUST use .SyncIgnore if you decide to delete some files/folders and you have multiple r/w nodes and some of them have already synced with those files that you have deleted, unless I am mistaken, of course. The other alternative for the case when some master node deleted some directory, is for other master nodes to also delete it. This is an "and" logic. Only if this AND that node contain the same data, then that data persists and databases would reconcile between the master nodes. So, if "and" logic was used, then if one master node changed a directory name by merely replacing the underline characters "_" with a blank " ", then the contents of both of these directories would disappear. From the information standpoint this would be a "loss of fidelity". The situation would cause loss of some information. So, the "or" logic or union operation seems to be more facilitating to the information presence or persistence. As far as information goes, logically, the "rule" is: no information should disappear. Duplicate copies are not as bad as information disappearance, at least for most cases. And if we end up with 2 copies of the same information because some master node decided to change the folder name into something "more suitable" in HIS opinion, while he, in fact, just created a 2nd copy of the same information, from the informational standpoint, this could be considered as noise and could be considered as nothing more than nuisance that does not cause the loss of information. According to the information theory, noise is something that does not carry information. This all means that the conflicts between the master nodes containing different information, as it stands now, are resolved via notion of a union to maintain the database consistency across all the r/w nodes. It could also be resolved via exclusion (the "and" operation), so all the nodes have the minimal amount of information present across all r/w nodes. But that would lead to information loss. One way to resolve it could be to have an external "arbiter", who would dictate HIS view on the information set, and any node, master or slave (r/o), has to comply to its reference view on the total information set. But in that case, there must be only one arbiter, probably the original creator of the information set, which also has a logical problem: if that creator sooner or later permanently leaves this share, then who becomes the arbiter from then on? It could probably be resolved by a rule: the arbiter is the one that has the most complete set of information. And if we have more than one arbiter, then we are back with the same problem, only now arbiters start fighting for the "right view" on aggregate information set. We are talking about one more type of node, the Reference Node. But then there is one other problem: what if the reference node is not on line? Do we create a notion of a dynamic or "current" reference node? But any way you look at it, this problem seems to be even more complex logically than even the problem with r/o nodes and it could turn out eventually that the current solution of using the .SyncIgnore is the most viable solution to accommodate for all the conflicting situations in the long run, and we just have to live with some unpleasant side effects if some r/w node does something inconsistent. This seems to be a tough cookie to crack...

Well, basically, the propagation logic gets extremely complex if you realize the myriad of things that may happen, like user modifies, deletes or renames some files (on r/o nodes), and then changes his mind and wants it all back in the original state, or file time stamps have been changes accidentally, different r/o nodes are in different state of completion, and on and on and on, the net effect may be not what user wants. So, to "fix" all these situations there is a "Restore Modified Files" feature, which simply means: go to the database and reset the "non-updatable" and "non-propagatable" bits of all the files, or whatever actually happens in btsync. That, in turn, causes the r/o node to "get in line" with the master node and any funk he might have created is simply nulled out and he gets the latest version of the master files, regardless of anything. At least that is the way I understand it at the moment. In terms of proposing any solutions or improvements, the product is not mature enough at the moment and this selective sync issue is quite a significant issue and plenty of people are talking about its effects. But I think the issue needs to be addressed in a more direct way. That is, provide a GUI based dialog box of Win Exploer type where user can click on any files or folders and exclude them from the sync, like it is done in may systems that insert the custom behavior to the Win Explorer and allow the user to make changes to defaults in terms of file selection. Yes, ultimately, it may be linked to automatic generation of .syncignore and its contents may be read to enable/disable the file/folder selection checkboxes in GUI. But, any way you cut it, I think the assumption that all the r/o nodes have to have the same .syncignore files is invalid, unenforceable and not quite logical, at least as it stands right now. The common paradigm is a file/folder viewer where you can click on + to expand the folders and click on a checkmark to enable/disable it syncing. This is not something revolutionary, but pretty common nowadays.

I think it is a bad idea to automatically sync .syncignore. Because it forces the r/o nodes to behave in the way the r/w nodes dictate. But any r/o node may wish to ignore some files, that are not in the master's vesion of .syncignore, like .avi or .mp3/4, etc. In that case, even if he modifies the .syncignore, but, in the future has some kind of problem and decides to "Restore modified files to original version", then his .syncignore will be overwritten from the master, and he may not even realize it, but he'll start downloading the humongous video or audio files that he would not want. I think the cleaner solution could be co create a .syncignore.master file where master proposes to ignore some files, which r/o node may or may not decide to copy to his main .syncignore. This way, the user has control of his situation. Furthermore, since master has some files in its .syncignore, that means that they will not even propagate to r/o nodes, in which case, what is the point of even having the same files in syncignore if you never receive them from the master in the first place? Do these files even exist in the database of the r/o nodes? So, either "Restore modified files to original version" has to allow the selection of files and, possibly, "All" checkbox, or .syncignore should not be overwritten by the master nodes. Another alternative could be to automatically copy the .syncignore.custom file, which user has to accommodate his interests, to the main .syncignore file after user clicks "Restore modified files to original version". It seems to me that the very idea of .syncignore is logically not quite consistent. Intuitively, each r/o node should have full fredom what it decides to ignore, regardless of other r/o nodes, that could have totally different syncignore files. Secondly, if master wants to exclude some files from propagation and puts them in its syncignore, the r/o nodes should not even know about those files. It seems that they should not even be in their databases. Thirdly, the user can override the master version of syncignore, at least the way it works right now, and master is not going to resync that file in the future because it will be marked as user modified file, not to be stepped upon. Basically, the less rigidity you have in your design and the less you impose things on user from the master - the better.

I just encountered a pretty nasty problem and it would be great if someone who knows what it means suggest some solution. I wanted to make sure that in my sync main folder on the master node (r/w) I have the latest version of the files (kept in a separate directory tree). So I did a cp -ru (instead of -rup) command via Cygrwin, which should not have touched the file update time stamps of files that are the same, but, unfortunately, it did modify the file update times. After a few minutes, I noticed that all the r/o nodes that are sitting on this share started to show that they are completely not in sync. When I realized that file times were changed, I did "Pause syncing" and then, when everyone have disappeared from Devices list, I hand copied the entire tree via Windows Explorer, so that it restores the old file update stamps. Then, after I reenabled syncing, all the r/o nodes show that they still need over 100 Mb of files to be updated, but they do not update for some reason. But the only thing that changed in those files was the file modification date, which was set to more recent date than they originally had and which was restored after I hand copied the files again restoring the original file mod dates. Furthermore, I hand modified one text file on the master node in order to see if r/o nodes are going to get the updated version. But not a single r/o node is getting the updated version of that file, and time stamp on it obviously later than when things got out of whack. That means that they will no longer receive the updates on some files. (Latest update on the above point: Well, I just checked now if I modify one file I do want propagated if it would update the other nodes. At the moment there was only one r/o node and that one did indeed updated with newer version. But there does not seem to be any r/w nodes on line at the moment. So... as they say "the jury is still out" on that one. We'll have to see more action in order to find out if this is true. May be someone knows this case for sure and could comment on it. That would be appreciated indeed.) I thought that if the only thing changes with the file on r/o node is the file modification date, then that file should not be downloaded again from the r/w node, and instead its modification time should be set to that of the master node. But this is not what seems to be happening. What is interesting is that since I edited one file for testing and it obviously had a newer modification date and still it did not propagate, then the issue has to do either with directory, the creation date of which was also modified, or with file status on r/o node and it was permanently marked as non-updatable and non-propagatable. Well, it look even worse than that now. I just looked at the Folders tab on the master node, and it show an error message: "Error: Bittorent Sync can not identify destination folder". What? So, it looks like that all the r/o nodes started to download the same exact files, just because their file mod date stamp has changed. Then, when I temporarily paused the syncing, they have distributed the "newer versions" of these files among all nodes, even though file were exactly the same, and then, when these files were restored back with their original date stamps, they refused to adjust their local date stamps to those of the master and permanently marked all those newly downloaded files as "bad" - non-updatable and non-propagatable. Why so? What am I missing here? So, does anyone know what it means and what can be done? They are probably fully synced because files with more recent time stamp would have the same hash - the contents did not change. Unfortunately, there is no way to tell those nodes to click on "Restore modified files to original version" button, which would probably fix this problem and they would show fully synced again. That is why I added a message on a Wishlist thread to either extend the device name column in Devices tab, or, better yet, add another column for the device message, which should have probably 1k characters in size, and, even if you can not see the whole thing, you should still be able to copy/paste it to your editor. I keep seeing the need to communicate a message from device again and again as I see some people are having some kind of problems and can not start syncing, or their clock is way too off, and even if I set a bigger range of time so that their error message disappears, they still do not start syncing. So, I'd like to communicate to the some message and they could probably reply to it by editing their device message. But this is another matter. Thanks in advance if you have a solution, and, better yet, if you fully explain what is exactly going on in this situation in a clear, step by step way, covering all the angles of it. Because this one definitely deserves to go into a detailed user manual I am working on right now.

I am glad you are happy. Can we assume that every single imaginable aspect of .SyncIgnore is covered now and not a single question remains? To RomanZ: Thanks a lot, appreciated indeed. It really helped to clarify some things. Your latest comments have been added to the master version of the manual. Looks like we've made quite some progress on this and related issues. If you think that this issue is fully covered, then we will consider its status: closed and fully covered (in our manual). If not, it would be great if you shed some light on missing points and/or some possible misunderstanding in my messages on this topic.

Question: What will be shown in the Devices tab if some files are excluded via .SyncIgnore? Will it still show that the node is fully synced? Or will it show some size still remaining to be uploaded? Related question: What does it mean if some node used to show that it is fully synced and then it just keeps showing that there is still some size to be uploaded, and never shows that it is fully synced since then? Does it mean that the user on r/o node deleted, modified or moved some files out of the sync path?

Well, thanks to your request, here comes the first version: Using .SyncIgnore file to exclude some files from syncing From the manual: .SyncIgnore is a regular text file (UTF-8 encoding) containing one file or folder per line. You can use "*" and "?" wildcards in .SyncIgnore files? "?" is a substitute for a single character instance and matches any character, "*" is a substitute for multiple character instances. Examples: *.dat would exclude from syncing all .dat files types regardless of name i.e. myfile.dat, anotherfile.dat, etc. abc???.dat would exclude from syncing files named "abc123.dat", "abcdef.dat", etc... but wouldn't exclude files named "abc1.dat" or "abcdefg.dat", etc *.mp? would exclude from syncing file types such as .mp3, .mp4, .mpa, etc, but wouldn't exclude file types such as .mpeg Video - exclude all the files in the directory Video on any level (depth) of the path. Video/*.avi - exclude all the .avi files in the directory Video on any level (depth) of the path. /Video - exclude the entire Video subfolder, but only if it is the TOP level subfolder. The effects of .SyncIgnore are more subtle that it might look at the first glance and file specifications are not intuitively obvious and behave slightly differently than they do in the O/S. In the following rules we will use the directory level notion, which is the same thing as directory depth in the file path. The 1st level is the root folder of the share. The 2nd level is a subfolder of the main folder, and so on. Rules File names are specified relative to the root directory (main sync folder), and not the absolute path in the file system. So, the absolute path E:\folder\share_folder\*.mp3 is incorrect specification and will not match anything. To specify the subfolders, file names are specified according to the same exact rules as on your O/S in respect to directory separator characters, ie to specify the subfolders, use the backslash character ("\") on Windows, and forward slach character on Linux ("/"). For example: /Audio/*.mp3 or \Audio\*.mp3 will exclude all the .mp3 files in subdirectory Audio of the main folder, but not in any other directory or subdirectory of any other level. If you specify some file name with or without wildcards, and your file name does NOT start with O/S dependent subfolder separator character ("/" or "\"), then btsync will check all the subfolders of all depths, from the root folder, down to the deepest level, and if it finds a file that matches the name(s) you specified, including the use of the wildcards, than those files will be considered a match and will be excluded. For example *.mp? will match any file of .mp3, .mp4, .mpa types in all the subfolders regardless of their depth in the path. If you want to exclude only files in the top level folder, then begin the file name with a directory separator character ("\" or "/"). For example: /*.mp3 will exclude the files of .mp3 type ONLY in the top level directory. If you want to exclude only files on a certain subfolder level, then you begin the file name with directory separator character, specify the mach specification for that level, possibly using the wildcard characters, then separator again, followed by the file name spec. For example, you have the following top level subfolders, Audio, Video, Books, and in the Books, you may have another subfolder, PDF, and you want to exclude only .txt files in any of top level subfolders. You would specify it as follows: /*/*.txt - exclude all the .txt files in the top level subfolders only (immediate subfolers of the root folder). /*/*/*.pdf - exclude all the .pdf files on the 2nd folder level deep. /*/PDF/*.pdf - exclude all the .pdf files on the 2nd folder level folder called PDF. The leading /* will match all the subfolders in the top level subfolders (Audio, Video, Books). Then, on the 2nd level deep subfolder, it will match the PDF subdirectory, and in that subdirectory it will match any .pdf file. Question about .SyncIgnore general behavior: Does it mean "do not update this file from the master (r/w) node (or any other r/o node that has the latest version of the file)? Or does it mean "do not propagate this file to other r/o nodes? Or both? Answer: Both. BTSync checks ignore list before requesting files from remote peers and never tells other peers that it has such file if it is in ignore list.

RomanZ, Thanks for your answers, appreciated indeed. We'll add it to our version of the detailed user manual. I hope you don't mind me being may be way too detailed and may be ask some questions that might be obvious. I just want to get every single thing we attempt to describe in as detailed way in in every conceivable permutation imaginable. So the whole thing should be clear even to the people with most basic knowledge about computers.

OK, I'd like to clarify the .syncIngore behavior once and for all and to add this info to the detailed user manual I am working on. So, please be patient with "stupid questions". I have seen a few posts on .syncIngore, but they look either scatchy or simply like guesses. So, what happens if leading slash is not present? (*.mp4)? Does it mean that it would be applicable to ALL subfolders on ALL the levels below the root folder of the share, which means that the folder traversal behavior is a default? Does leading slash mean "override folder traversal"? Because on the O/S level the spec *.mp4 would be interpreted as the immediate or current directory (as expanded by the shell), or top level folder for the share, [unless -R or -r command line flag is specified for many standard utilities]. So, is it correct to interpret the leading slash as the top folder for the share, and not the absolute path (root folder of a device on the O/S level)? Can we assume that on Windows the above specs would be: \*.mp4 \*.avi and the only difference on Linux and Win is that you use backslashes instead of forward slashes? Because I have seen some post somewhere, where one guy tried to use the following spec on Win: E:\folder\share_folder\*.mp3 where share_folder is the top folder for the node, which means the absolute path on the O/S level. This seems to be incorrect as that would imply that you can access the files outside of the root folder for the share, which is absurd. Or, would this syntax be correct as well? Qutestions: 1) When you want to ignore things on certain level under top folder, say, for example, files in the immediate subfolder, is the following syntax correct? /*/*.avi (ignores *.avi files in all the immediate subfolers of the root folder of the share) /*/*/*.avi (the same, but on the 2nd deeper level) 3) Is syntax of *.avi equivalent to ignore in the subfolders of ANY depth? 4) I have seen spec like /**/*.avi What does double star mean, if this is a valid spec?

There is a proposal for improvement of update and propagate logic for the r/o nodes, unless we are missing something, of course. See: Current file update and propagation logic problems http://forum.bittorrent.com/topic/28114-btsync-file-transfer-behavior-table/#entry79400

Current file update and propagation logic problems BT probably knows about these issue better and their opinion would be more appropriate.

Note: "Btsync File Transfer Behavior Table" was updated and significantly expanded. There was a number of errors in the original version that were corrected here to the best of my understanding at the moment. So, now, hopefully, we are getting a little bit closer to "how it REALLY is". But, unless we have comments from either support or developers, you shouldn't rely on this information as something totally reliable and correct.

Note: In current context, this article is no longer relevant.

I think BTSync team is more authoritive source of user documentation.

Selective sync and propagation This seems to be a topic of concern to quite a few people and it is an important issue. There is a need to chose which exact files to exclude from syncing. For example, you might have some notes, some files containing private and/or non-public information, or other files that are not a part of distributable information. Or you may have the temporary files, such as raw text version of the html pages that you use as a scratchpad or the original source. You would not want to propagate these files from the master (r/w) node to any r/o nodes. The same thing is applicable to the r/o nodes. Whatever the reason this is not currently possible may have its own logic and it was done for purpose. But the problem is that in some cases it will not be quite possible to make every single decision automatically, depending on a number of conditions. For example, if you made a mistake and modified or removed some file. In that case, with current automatic logic, the file becomes non-propagatable. But this is not necessarily what you would like to happen. Or, after a while, you decided to exclude some other files from propagation, at least from now on. So, it is basically logically impossible to create an automatic logic to accommodate all possible conditions. No matter what you do with logic, you will pretty much inevitably come to some contradiction and/or uncertainty that can not be resolved automatically without user intervention. Therefore, there is a compelling need to individually adjust the behavior of any file or entire subfolder not automatically, with preset logic, but manually. This could be done by displaying an explorer kind of popup box where you could click on some folder and expand it and then right click on some file in order to modify a number of things. There is a need for an easy way to see which files are a part of the distributable share by displaying a checkbox next to them indicating that they indeed are. You might have several checkboxes indicating different things. When one right clicks on a file, he should see a popup box, like properties, where you have a number of choices, such as restore the original propagation status of this file, include/exclude it from propagating, resync file contents from the master right now, and so on. Or, alternatively, you could have a stand-alone executable to access the database and make these adjustments if this is undesirable to do it directly from btsync GUI. You might want to automatically suspend the operations of the main btsync while you are modifying things and then restart it agian when you exit the dialog box by clicking OK button. You would probably need to authenticate the user before you allow to make any changes to the database. On the Linux end, you might simply have a separate executable to modify the database with command line interface. Even that would be sufficient for vast majority of cases. One of the options to the command line is operation (mark non propagatable, resync, restore from master, etc.) followed by the file name argument. In this case, shell will do standard file name expansion for you. One other thing you might want to provide is the command to display all the files that will NOT propagate. One more would be to output the list of all files that had the propagation errors and the exact reason for those errors, fully expanded in a user readable manner instead of displaying some meaningless hash strings (those could be printed in parens at the end of the message). This would be great. Because the way it is right now, it is a major hassle in our case and it takes way too much time and creates way too many problems. We would not like to write the shell scripts to tell btsync not to sync some files by cheating it and deleting the file and then run another script to restore those files assuming that from now on they will not propagate.

To developers, Hi guys, It would be great to have a complete and precise BTSync file transfer logic for all the cases of file creation, removal, removal and restoration, name change, file permission change, etc. Would any of you look at this thread and correct or expand the description or whatever you feel like clarifying. This seems to be significantly complex issue and needs complete clarification of btsync behavior. Otherwise, the consequences may be highly unpleasant to the users. http://forum.bittorrent.com/topic/28114-btsync-file-transfer-behavior-table/?p=79178 If any of you decide to do so and either edit the existing post or write a new post with specific and precise comments, the original post will be edited so that description is correct, precise and complete. This will be added to the detailed user manual I am writing that has all the details about tricky or non-apparent issues of btsync behavior.

BTSync File Transfer Behavior Table Since there was no feedback, there is no point in this article.

A Message from Devices It would be great to have a message from a device, either as an additional column in the Devices tab, or in a popup if you click on some device to show a longer text than it currently shows in Device column on the Devices tab. The reason for this is for the device to post some message to other devices if, for example it has some problems or it wants to provide the additional information beyond device name, such as posting the upcoming key change or when the devices is going to be on/off-line, to provide some url or invite people to join some chat, or anything else the device would like to inform others about. Right now the max length of the Device column is 98 characters. That is not sufficient as a general purpose message, and if you start adding an extra text to the Device name string, things may get a little confusing. At the very least, it would be desirable to increase the max length of the Device string to at least 256 chars or something like that. That way, if the string is too long to be seen as a device name, at least you could copy it to the clipboard and paste it to your notepad to see the full text without expanding the Device name column. The bottom line is: There may be a number of reasons for the device to display a more lengthy message to r/o devices. Basically, there is no compelling reason NOT to allow devices to communicate with each other and there IS a compelling reason for them to be able to do so. For example, right now I am seeing one node that is sitting dead for over a week on one of the shares. This simply does not make any sense and there is no way to help that guy or to find out the reason he is sitting there for days and weeks without actually downloading the share.

I am seeing one node on one of shares that sits there for weeks and does not download anything as it shows that the amount to be uploaded to it is basically the whole share. How could this happen and what could be going on? It seems to be improbable that when that user added some share it was possible to make the entire folder not writable by btsync. So, unless he explicitly made the top folder r/o by hand-creating that folder under his own user account and not via btsync dialog box, it is not clear why don't I see him downloading for weeks? I made my "Device name" string to contain the message to him. But he does not seem to reply. Could it be that he does not even SEE me? For all I care, I'd like to block and/or ban him from this share because it looks funky to me.

There is not point in long posts.

No point in long posts.

Yep.