SamD

@RomanZ All directories and files stay in place. When I say "suppress", I mean "suppress in Sync" that is to say, I press the "minus" button in the mac os x GUI for instance. Is it wrong? Yes item 1 worked. Item 2 failed : after I remove F1 from sync and give the same RW secret to another yet empty folder F2 _ using the + button _ (but F1 is still on C1), the backup on C2 was not restored on C1 (into F2). C2 BTSync-GUI mentions that C1 is online and that sync have been done: so it's stuck at item 1. That's it. Item 3 failed : On C1, I remove F2 from sync (- button) and add back F1 (+ button) with original RW secret (starting with D), all files, which are already synchronized, are analyzed and added to the list to be synchronized with C2 but nothing happens.

Hi, don't know what to do to have BTSync working again. It stopped synchronizing? Scenario: 1- computer C1 sync a folder F1 on computer C2 with RW-secret starting with D*** on C1 and ERO-secret starting with F***. Synchronization starts and ends correctly. 2- I suppress F1 from BTSync on C1 and add newly created folder F2 with the same RW-secret as before (F1 suppressed so there is no issue of two folders having the same secret). Both machines see each other so I expect data recovery from the backup computer C2. But nothing happens. 3- I suppress F2 on C1 and add back F1 with the D** RW-secret. All files are added but sync does not work any more. I add a new file for instance, and it is clearly added to the list of files to load, but nothing happens, although both computers see each other... As I check the log files, I see plenty of "Merge: will request nodes for...." How to correctly "reboot" BTSync? I tried several time to close-start it on both machines...

HI, Sorry it took me a while to give some feedback on this. I found the glitch. I found out the BTSync was doing the right thing. I mean, I did not find that "conflicts" in BTSync is straightforward. It really is messing up files, and BTSync team might want to rethink the way conflicts are handled (for instance, letting the user to solve conflicts by some batch processing with simple actions). But the conflict reason was right. Indeed, I discovered that I have very many files with French-German-Spanish-Portuguese-... accents in the filename. After quite some research, I found out that RSYNC was not used properly. If both Linux ext and MacOS HFS are using UTF8 encoding, MacOS is using a special UTF8 (of course why are the standards for?). So that I had to tell RSYNC to convert from Mac UTF8 to Linux UTF8, otherwise, as properly detected by BTSync, file naming is not the same on both side. in addition, file metadata (xattr) are not passed properly : I have no idea whether I shall bother, nor if BTSync bothers... I abandoned this issue. So here is the correct way to use RSYNC for me so that no conflicts are detected by BTSync afterwards: rsync -asz --progress -e 'ssh -p 22' --iconv=UTF8-MAC,UTF-8 --delete --backup --backup-dir=/home/me/RSyncTrash /Volumes/myDisk/Users/me/myFolder2Sync/ url2myServer:/home/me/myFolder2SyncSources: here is an explanation on how rsync deals with spaces in the filename (https://rsync.samba.org/FAQ.html#9) and here is a blog explaining that rsync on OS X is buggy (version 2.6) and should be upgraded to version 3.0.9 (http://elliotli.blogspot.se/2011/10/using-rsync-to-migrate-data-between.html). Hope it will help.

I was hoping it works that easily. But nothing is synchronized back. Similar test scenario : - source mac os : folder sync with D type key (RW) - backup linux : folder sync with F type key (E-RO) After sync is finished, tested (for renaming, deletion, update), I remove from BTSync GUI the original folder on source machine and try to reverse the process. So I add a new (empty) folder with the D type secret. As there is no .sync subfolder, nothing get deleted on the backup machine: good. But nothing is restored, and that is a problem. I don't find a way to "force" BTSync to restore the data... :/ Help?

I found a beginning of explanation here: https://rsync.samba.org/FAQ.html#2 It seems that synchronization is more an art than I thought. At least rsync people are giving a great hint here. My best piece: I would do more test about it as I indeed use HFS+ on my Mac. Could BitTorrent Sync people tell us more about dealing with filesystem?

@RomanZ Yes, most files affected have French or German or Swedish special characters like éèùàëîïöëçåßæœ and upper case. It seems that in total it is 25% of the files that are affected: I did not remember it was so many But some files don't contain special character. So I am sending the logs. Now what about it? Why is there conflict produced by special characters? I guess most of your European users would love that you don't limit yourself to US charaters Do BTSync developpers plan to correct this soon?

thx for reply @RomanZ One side is Linux Ubuntu, other side is Mac Os X. So it should not be the problem. As I said, intinial sync was made with RSYNC which preserves naming, case, and date (with the option t or equivalently a). Rsync is a command I apply from time to time, it is not running in the background. And conflicts are not affecting some files, they are concerning most files (if any, I did not let corrupt the whole folder) and some subfolders. OsX is setup in French, Ubuntu most probably in English or eventually in German. I don't see why this could affect anything (at least it is not an issue with rsync), but I mention this because of what you told in an other post.

Is it selective sync ? Or streaming (friends could download what they really want from your playlist...) ? +1 for both

To BitTorrent Sync contributors: Here is an idea. I could try to rsync back the btsync i386 application and associated files on my Mac so that files are hashed the same way. I could try to make a diff to see what's different in the database. Or I could just edit the downloaded db (but you'd have to tell me how) so that I can specify the path to the "equivalent" folder, thus using a synchronized db to avoid this initial conflict mess? What do you think? Does it have any chance to go anywhere?

Same problem here, but not solved it seems... http://forum.bittorrent.com/topic/29508-sync-folder-on-two-computers-after-copying-files-to-each/

To what I undestrand, there is conflict when a file is different on 2 machines, that is, size is different and-or date is different. Is checksum verified? I tried to look at the logs to see if there is something written about conflict detection: it seems it is recording connection and nothing about indexing or conflict detection. When a file is modified, just the portion of the file affected is transmitted, right? Why, when there is a conflict, both files are fully transmitted?

Hi I need help on this one, as I don't know what could be my next attempt. Scenario: two computers, one-way synchronized with rsync for years (archive and delete option, that make that date-time is same on both side). More than 1,2To that I obviously don't want to upload again. On both side I use a secret starting with D (RW-secret). The main folder is added to btsync, and indexing works fine (same number of files as it should be). I verified using 'date' on both side (over ssh) that it answers the same time CEST. Although I used rsync with checksum control in both direction, when synchronization starts, catastrophy... All files are marked as conflict and sent in both direction. Pure mess... I have no idea what to do? Any advice is gladly welcome. Cheers, S. -- BitTorrent Sync v. 1.3.105 (latest)