fatso83

That is plain wrong. Hard to believe perhaps, but there are hundreds and thousands of known bugs in all production software. There is simply a prioritization of what is worth doing at a given time. Some bugs will never be fixed, others will. There are for instance about 60 000 open and known bugs or issues at the present time in Chrome - the worlds most popular browser, made by some of the world's best paid talent. So it's just a reality of life: bugfree software doesn't exist.

From time to time we need to google our way to this article in order to fix the problem of the Finder integration not working. Searching for this problem on the forums shows that it is still a quite recurrent theme these days. I remember having issues with this in 2014. Three years later, this is still a thing, and the number one annoyance with Sync in our office. Should Resilio invest a little more effort into fixing this thing? I mean, Dropbox is essentially having the same desktop integration, and I have had a problem with that since using that in 2009. What about doing some cleanup/resetting related to this each time the machine is restarted to ensure this thing keeps on working (probably something you already do, but still ...)?

Has this situation been improved?

I have gotten great support from you guys, but waiting a weekend is not so hot when you are in a different time zone and stuff is halting production on Monday (which is starting 10 hours before you guys get to work). Maybe you should have an option of paid premium+ support for people that require immediate assistance, possibly off-hours? Way cheaper to pay 50$ for immediate support than having three people unable to sync their work for two days.

I just had to try and resolve an issue for my wife's company that I assume has been building up for a while: indexing never finished and after looking into it they had 1.4 million conflict folders under one specific subfolder. The number was increasing by the minute ... Fixing this took quite some time (one hours on a Fusion drive, 4 minutes on a SSD), and required some tinkering (and support from you guys), but I think it never should have gotten this far. To me, creating millions of folder is a bug, no matter the background for how they are created, and I think the process should be stopped before it spins out of control like it did here.

Just after adding a new share (for instance after clicking a sharing link) one can click the peers column and see the connected peers. Until file transfers actually start it will have a green tick next to the other peers saying "Synced", even though no such thing has yet occurred. That is a bit misleading, and is one of several minor UI/UX bugs related to statuses.

I know that Sync stored earlier file versions in its .sync/Archive folder, but most people using it does not know. People don't read documentation. So I think that when right-clicking a file in Finder (or Explorer) one should be presented with a way of choosing an earlier file version. The dialog should show these fields for each file/folder When was the file created When was it overwritten by the next version Which peer (user+device) had the change that triggered the overwrite/deletion I know that is what proper backups systems are for, but this eases debugging sync issues (which is hard enough as it is), and sending you debug logs every time does not scale :-)

I think a key missing feature from Sync is stopping errors from propagating by interacting with the user and presenting her with options on what one can do. As an example, I recently filed an issue #49958 where the indexing was out of control. It turned out that due to some naming conflict (probably due to the composed/decomposed issue) *.Conflict folders were being created. By the time we found out why indexing never finished 1.4 million such conflict folders had been created for one particular weirdly named folder. When stuff like that happens Sync should notify the user that something really fishy is going on (ok, I am a programmer so I know that is way too wide description to implement, but you get the gist) and some possible solutions like: Folder X is causing conflicts because of naming issues. These are your options for fixing the problem: - Notify user X that the created file Y has a filename causing problems and ask her to rename the folder - Do X - Do Y We will stop sync for this subfolder/item until the problem has been fixed. If there had been some kind of "cross-network error diagnostics" built into the protocol maybe errors that arise on another peer than the one that created the filename can be propagated back to the origin to fix the error in the source. AFAIK only the "destination" peer gets any info through the GUI that a filename contains illegal characters, and from my experience they have no idea what to do about it (if they even understand it's a problem).

Really wish Resilio had a way of voting for features that was better than +1, but here goes. +1 for me too. I have no idea if it's the sheer number of files or something else that is tripping up the 50GB common share at work, but it sure as hell is annoying not to know if there is any progress.

I am backing up my Windows Phone pictures using Bittorrent Sync, and when it (finally) connects to my Mac it usually works fine. But I can never get the sync to fully finish as BT Sync on my Mac says it is trying to copy "809 files to" my Windows Phone. Which is strange, given that my Mac got a read-only link from the mobile device ... Something seems fishy here :-/

We have no idea what is the cause of the above errors, but deleting all the conflicting folders seems to have fixed things. For now ... we have turned off syncing on a few other computers, so we will see once we start hooking them up again. This is what I have done so far # Find all conflicting folders and list its contents find /Users/Frost/BitTorrent\ Sync/Frost\ Arkitekter/ -type d -name '*Conflict*' -print0 |sudo xargs -0 ls # Delete all empty conflicting folders find /Users/Frost/BitTorrent\ Sync/Frost\ Arkitekter/ -type d -name '*Conflict*' -print0 |sudo xargs -0 rmdir # After inspecting the remaining folders (see first command), moving any important files to the original folder, # start deleting all the remaining conflicting folders find /Users/Frost/BitTorrent\ Sync/Frost\ Arkitekter/ -type d -name '*Conflict*' -print0 |sudo xargs -0 /bin/rm -r

We have a problem with sync producing hundreds of (usually empty) *.Conflict folders and the debug log is producing 100MB per hour of crap. A lot of it is stuff like: [20160412 10:00:01.486] JOURNAL[0123]: won't perform job for entry "Admin/Admin/DAGLIG DRIFT/ANSETTELSER/Petter Gillebo/215.05 Tidsbegrenset arbeids.textClipping/com.apple.ResourceFork" - parent has fs error [20160412 10:00:01.486] JOURNAL[0123]: Setup entry job "FileEntryJob" for path "Admin/Admin/DAGLIG DRIFT/ANSETTELSER/Petter Gillebo/215.05 Tidsbegrenset arbeids.textClipping/com.apple.ResourceFork", next state is "COMPLETE", queue size 0 313 0 [20160412 10:00:01.486] JOURNAL[0123]: remote entry job complete for entry "/Users/IngerFrost/BitTorrent Sync/Frost Arkitekter/Admin/Admin/DAGLIG DRIFT/ANSETTELSER/JohnDoe/215.05 Tidsbegrenset arbeids.textClipping/com.apple.ResourceFork" [20160412 10:00:01.486] JOURNAL[0123]: { "dl_failed": false, "file_hash": "DEC4716639E4E60F2A05A151B8AFCC78D245A3A2", "file_id": "0:0", "fs_error": true, "have_pieces": 0, "ignored": false, "info_hash": "4C0B4E3E487D7F5B5DF605A3C276139C17097C87", "invalidated": false, "link_content": "", "locked": false, "mtime": -1, "name_on_disk": "com.apple.ResourceFork", "otime": 51706, "owner": "106BCD002BBCE0DA447EBF1B2FA921A48A92B104", "path": "/Users/IngerFrost/BitTorrent Sync/Frost Arkitekter/Admin/Admin/DAGLIG DRIFT/ANSETTELSER/JohnDoe/215.05 Tidsbegrenset arbeids.textClipping/com.apple.ResourceFork", "perm": 0, "ph_ext": ".bts", "placeholder": false, "pvi": "pvi[NULL]", "selected_for_dl": true, "size": 582, "state": 1, "time": 1460406692, "total_pieces": 1, "type": 5 } [20160412 10:00:01.486] JOURNAL[0123]: won't perform job for entry "Admin/Admin/DAGLIG DRIFT/ANSETTELSER/JaneWalther" - parent has fs error We have restarted the mac and sync several times. We have no idea how to debug this further. Pointers? log.zip

Aha. That could have been easier to come across, but is fine. Still, think showing the 1.4 is a bit misleading to users as they will think they are somehow stuck on an old version. I would have tried to gloss over the actual technical details for new users by specially handling these 1.4 read-only folders with a "Read-only backup" distinction, rather than implying you're running some kind of legacy thing by stating it's a version 1.4 folder. My 2 cents. Would have saved me two hours of googling for variations on "Sync won't upgrade 1.4 folder 2.0" / "BTSync stuck on 1.4 backup", etc. Thanks for the link.

To be clear, what you are saying is this: new users of Sync that turn on Camera Backup will get 2.0-style backupsold users of Sync and Camera Backup will get 1.4-style backups no matter what they doDo I understand you correctly? Because right now I have been trying for an hour trying to remove all traces of Sync 1.4 ever being used to sync my Camera Backup folder, disconnecting and removing the folder from all other computers and deleting the .sync folder, but upon re-enabling it still shows up as 1.4 on the other computers.

I think I have a reasonably simple folder that I am sharing: approx 3.8GB and 3800 files. I have a 50Mbit connection, so downloading it from the existing computers over the internet gives me about 3-5 MB/s. This means I can go from 0% to 100% in less than ten minutes. Now I needed to move the shared folder on my local server, and to save time, I followed the instructions on how to unshare, move, and then re-add the existing folder using the old key. This seems to work, but is excruciatingly slow! After waiting 30 minutes it has reached 11%. This is repeatable (just quit Sync and it will restart at 0%). It is not like it is stuck, as I see lots of action in the (debug) logs. This can't be right? -- Edit: I have verified this to happen both on my MacBook Pro (2013, 16GB, SSD) and my server (weak, AMD dualcore anno 2006, 2GB)

For some reason copying the debconf-default.conf to a new file name causes the service to fail, but renaming the file will work! This must be some kind of weird bug. I have never seen that behaviour in any software before. Is there some kind of hardlink mystery going on here? Taking a gander at my experiment below should hopefully be enlightening. root@ip-172-31-34-81:/etc/btsync# /etc/init.d/btsync start * Autostarting btsync instance 'debconf-default' [ OK ] root@ip-172-31-34-81:/etc/btsync# /etc/init.d/btsync stop * Stopping btsync instance 'debconf-default' [ OK ] root@ip-172-31-34-81:/etc/btsync# mv debconf-default.conf test.confroot@ip-172-31-34-81:/etc/btsync# /etc/init.d/btsync start * Autostarting btsync instance 'test' [ OK ] root@ip-172-31-34-81:/etc/btsync# /etc/init.d/btsync stop * Stopping btsync instance 'test' [ OK ] root@ip-172-31-34-81:/etc/btsync# mv test.conf debconf-default.conf.bakroot@ip-172-31-34-81:/etc/btsync# cp debconf-default.conf.bak test.confroot@ip-172-31-34-81:/etc/btsync# /etc/init.d/btsync start * Autostarting btsync instance 'test' * Failed to start btsync instance test - please check the configuration file /etc/btsync/test.confroot@ip-172-31-34-81:/etc/btsync# md5sum test.conf debconf-default.conf.bak b2ab63cf544cc65ca506c417f19642ad test.confb2ab63cf544cc65ca506c417f19642ad debconf-default.conf.bak

I know I can share folders using the GUI by creating a sharing link and send it to another client. Opening this link in the other client will add the folder. This works fine. But I have problems when trying to add a folder in Linux when not using the web ui. In the config file (i.e. my-shares.conf), each shared folder in the shared_folders section requires a field called secret. Where can I find this value? Is it one of the five parameters (sz, s, i, p, e) in the sharing link that is generated in the GUI clients? Can I get it from the .sync directory containing the settings? I tried adding the 32 character value I found there, but just got an error saying it was an illegal value, and it does not resemble the 21 character value found in the user.conf sample config I found ("bGTbrwreXPW4XxHEmTKnX"). -- SOLUTION: Press the triple vertical dots on the share, then Preferences in the dialog that comes up, then press "View key" at the bottom of the preferences window.

The bug is still present ...

Great to hear! Its been hard to market this for non-techies when my demos just shows dummy text.

When pressing "Share" on a folder, and then generating a QR code, there is a link called "Scan with the Sync mobile app". It leads to a 404 page.

Have I somehow managed to post to the wrong forum, or something? There is very little progress on this matter, even though it affects a whole mass of users.

Downloaded the program, chose to share a folder using email, and got the following dialogs. As is apparant there is absolutely no real text showing except the dummy text for the templates. Not too professional :-/ If this works for other users, my guess is that it is related to localization. Perhaps there were no strings found for the "no" (Norwegian) locale, and instead of resorting to English, it spit out dummy text