visnumber

Had the same problem for a LONG time and the reason is simple: permissions! You delete a folder on one machine, but the other cannot delete it because the folder has insufficient permissions (on that machine). So the first machine thinks "the folder is back" and copies it back. I change the permissions on all 3 machines to allow everybody read and write and the problem was gone. I wonder why BTS does not warn about this.

Same problem here with me. 2.3.3. causes some indexing problems that were not there in 2.3.2.

Dear RomanZ! The issue is still there: I moved the photos IMG_6164B.JPG IMG_6165B.JPG IMG_6166B.JPG IMG_6167B.JPG IMG_6168B.JPG IMG_6169B.JPG IMG_6170B.JPG IMG_6171B.JPG IMG_6172B.JPG IMG_6173B.JPG IMG_6174B.JPG IMG_6175B.JPG IMG_6176B.JPG IMG_6177B.JPG IMG_6178B.JPG IMG_6179B.JPG IMG_6180B.JPG IMG_6184B.MOV IMG_6185B.JPG IMG_6187B.JPG IMG_6213.JPG IMG_6214.JPG IMG_6215.JPG altogether to a new subfolder called Fotos Anja Virgil Kinder/20140401 Zino Oskar Sol April 2014/Digitalfotos and they were again deleted and added (and thus copied again). Renaming seems to work if I only move a single file. But with many it does not. Log is here: https://dl.dropboxusercontent.com/u/55874826/sync.log Thanks Virgil

Same with me on 1.3.94 with 1 iMac, 2 MacBooks Pro (all Mavericks) and one old MiniMac. Initial syncing of 1 TB (divided into about 10 different sync-Folders) takes many days although all folders are identical and nothing needs to be copied. After a while all folders are shown as indexed completely but the arrow-symbols indicate that the larger folders are not complete (like 62 GB left to upload and 12 GB left to download). Those values almost never change or only a few MBs per day. Nevertheless smaller sync-Folders are synced right away, the bigger ones are synced, too. But sometimes half an hour later or even a day later. Don't see a pattern. As of version 1.3 there seems to be another slowing down issue with extended attributes (which are very welcome!) There are some old files (15 years old) and some newer ones (usually from outside customers, maybe of windows origin) where the attributes cannot be synced. (The files exist on all machines already!) BTS tries to sync them frantically again and again, heating up all the macs and making the fan spin like crazy for hours. CPU is on 100% and more. BTS then stops syncing other files (like ones I am working on right now), gets stuck (leaving many !sync-files) and needs to be restarted. After restarts it quickly resyncs my new files and falls back into the old routine of heat, fan, CPU etc... after a few hours. In the last versions before 1.3 this was not a problem any more after about 2 days of initial indexing.....

Renaming a folder inside a sync-Folder often results in remove/re-upload of the entire content. This was mentioned by several users. A test of me showed that this seems to be happening when the folder name contains special characters like German umlaute. Renaming a Folder "Frühstück" to "Frühstück 2" results in removal of all the files a complete re-upload. Renaming the Folder "Frühstück" to "Fruehstueck 2" results in the correct renaming. Maybe something for the BTS-team to check... Considering the "conflict"-discussion about the Umlaute it would not surprise me if I am on to something here.....

There is a problem with this, even in 1.3.89: it shows many GB of "unsynced" files (identical already, anyway) but does not transfer anything. All this was working well in pre 1.3. Does it resync als the ressource forks now and fails with prehistoric files? Seems to be stuck all the time on several macs.

Umlaute in a Folder name create .Conflict in BTS 1.3.77 on Macs. There is clearly a bug, I had it in many folders. If the folder name contains an "Umlaut" like ä ü ö etc. then the folder will be marked as a conflict-Folder and duplicated but ONLY if it is the root folder of a sync folder. It does not happen in deeper levels. You have to create a new folder without umlaut, move the contents of both old folders (.Conflict and without .Confict) to the new one, that works. Not a pleasant bug in german speaking countries and many more....

And, dear makers of BitTorrentSync, when can we expect an update after such a long time waiting?

Hi! Update: I am now again on version 1.2.82 and it works fine. Important issues are still: - Renaming often not recognized as such, resulting in new unnecessary uploads - Aliases not resolved - the tab "devices" in some folders never shows a complete initial sync but it does sync correctly. - No new version for 3 months :-( Best!

Finder refresh on OS 10.9.1. with BTS 1.2.82: sometimes the finder windows don't show new files or folders. It looks as if they were not copied, scrolling does not show them. But as soon as you change something else in the window (e.g. add another file) it is refreshed and suddenly the new file/folder is here. Does not only happen with windows which were open when the sync took place. Happens irregularly but not infrequently... Anybody else experiencing this?

Have the same problem: when I rename photos about one third of them are "renamed" and not uploaded again, the other are "removed" and "added" again - thus uploading them all again... what is the reason? BTS is also not so tolerant with folder name changes - have not yet figured out when it does what.

Update to my post of Yesterday, 11:41 PM : Downgraded to 1.2.68 and it immediately synced everything again....

Hi! I have the same problem since 1.2.73 on three Macs with several folders including a zillion files (no SymLinks included). Up to version 1.2.68 syncing happened almost in an instant. Now it takes 30 min up to several hours to detect changes and sync them to the other machines. (Also to show them in the history takes very long and it even says "Machine X synced at xx:yy" showing a time AFTER an unrecognized change happened that was not shown in the history and only really happens hours later.) Tested it in all directions with small files, also re-added folders to re-index them. Did not help. My guess: it has to do with the changes you did to indexing (to stop infinite indexing) OR it did not like the "running upgrade" from 1.2.68 to 1.2.73 without a clean re-indexing. Have not changed anything else in my set-up that worked well for many weeks. Thanks!