BeTheSync

Thanks RomanZ, u got the message, yes, newer files are still (reproducable) overwritten. (My Operating Systems are: Win7: Windows7 64Bit newest Hotfixes (16GB RAM) Mac: MacBookPro w/ Mavericks OSX 10.9.4. (8GB RAM) Linux: Synology NAS DS1813+ (4GB RAM) )

@RomanZ: ReThinking what u've initially said about the *.db-wal / *.db-shm files, and testing the scenario again the last night, the problem still occurs. (This time, I gave btsync on the Win7 and Linux enough time to write their db-files to the disk, and checked for "ungracefully files: no files, beside the ones from 2013, I mentioned in my post above.) It seems not a matter of interrupting btsync while shutting down the computers, but more a problem with the number of files/folders to catch up, when btsync is restarting. (well, actually, it was obvious to me before, but the *.db-wal / *.db-shm zombie files were a good attempt to re-check this situation here, just to know and eliminate some more causes ...) Writing this, I see btsync is overwriting some newer, touched files from the Win7 Computer with older ones from the Linux Machine, which I both rebootet several times as describes in my above post. (but checking, that the processes shutted down clear and left no files, like *.db-wal / *.db-shm) So the question here is: what is the maximum number of files/folders btsync should be capable to work with? (I guess, its not easy to answer because its depends on the speed of the computer and disks and filesystem, etc...)

The wal&shm files are present when btsync crashed, of course. They are removed (or renewed) every time, btsync starts. When btsync runs for some days and I quit it normally (i.e. w/o rebooting) the files you mentioned are not present, but I found some *.db / *.db-wal / *.db-shm files dated early 2013. Can I safely delete them? Anyways, it seems obvious, that btsync cannot write its files decently to the SSD, as a course of the problem, but knowing abot the reason, does not solve the problem :-)

To reproduce such a szenario, this works for me *all the time* without an exception: (I reference on btsync 1.3 here, but the problem still exists in 1.4!) R/W share with about >300.000 files, spread in about 15.000 folders on a Win7 NTFS Harddrive (or SSD). (about 100GB in size) R/W Share on a linux NAS for that folder. (my exact data: 102.957.787.521 Bytes in 309.654 files, spread on 15.384 folders) Both shares (Win/Linux) are synced and identical. (Important: u need to have other large R/W or R/O shares configured in btsync too. In Win7 to Linux. So btsync has a lot of work to do, while stoping or starting!! I have about 20 shares with a overall size of 2.4TB (my exact data: 2.536.255.076.315 Bytes in 2.551.737 files, spread on 153.502 folders)) Delete or change (i.e. rotate a graphic file) some files from some folders of the win7 Computer.Keep an eye on the transfers and make sure, some of the changed files (not all) are synced to the Linux Machine. (btw. you can't keep an eye on the transfers in 1.4, which really really isn't helpful!) While you restart the linux btsync (or rebot the machine) change more files on the win7 Computer.While the Linux Machine btsync is starting (here it takes about 10-30 minutes here for the webgui to show all the shares, because of the huge indexing procedure, I guess) just stop or restart the Win7 Computer btsync some times, like it is needed to reboot some times for Windows-updates in a row. When u repeat those steps several times (restarting btsync while indexing and/or transfer of files is interrupted), the deleted files on the Win7 Computer keep coming back from the Linux Machine at some time or the changed files on the Win7 Computer are overwritten by older ones from the Linux Machine. Now consider, when u delete or change (i.e. rotate image files) some files on the Linux Machine as well as on the Win7 Computer, what a mess btsync is creating... btw: when u repeat thos steps, u will realize sometimes, that btsync is apparently working, but no files are transfered since a long time (ie. 2 days). When u then restart btsync, transfers go on as usual. thats what happens here a lot (on Win7 Computer *and* Linux Machine) In the end, its just a "normal" situation, where ppl need to restart their computers some time, while btsync is indexing or transfering and therefore btsync can't keep up with the changes, I guess, because I'm monitor this since a long time and the reasons seem always the same, because my behaviour keeps the same :-) Anyways, thats not a funny behaviour of btsync and should be addressed/fixed soon.

Unofficially, its possible, but its work you need to do! first: stop btsync. (if you have a machine where u not upgraded to 1.4 and used all the *same* shared folders there, u're lucky. Just check all your shared folders for those hidden files ".SyncID" and ".SyncIgnore" and copy them to the *same* shared folders on the machine u just upgraded.) Otherwise: U need to check all your shared folders on your machines where u have upgraded to 1.4 for files/folders in a hidden folder named ".sync". Those files are: "ID" and "IgnoreList". There are maybe some other files like "StreamsList" or folders like "Streams" or "Archive" but u can ignore them. Well, I did, because u can't restore them for use in 1.3. -File "ID" is the former ".SyncID" (ID of the folder, which is used by btsync to identificate the folder as a sync folder, and which sync folder it is) -File "IgnoreList" is the former ".SyncIgnore" (is used to ignore several files/folders while syncing. not important as the "ID".) -Folder "Archive" is the former ".SyncArchive" (the recycler folder of btsync. U need to know yourself, if u need those files, because they were deleted by btsync before and u probably have newer files in the shared folder itself.) What do u need to do with those two important files "ID and "IgnoreList" in the ".sync" folder? U need to rename them back to their original filenames (see above) and copy them in your shared folder, so 1.3 can use them again, after you installed 1.3 over 1.4, which is simply done by starting a copy of the btsync install file of 1.3. (do not start btsync after installing, if you're not finished to copy all those files back to its original location!) U need to rename and copy those files for *each* shared folder u want to use again in 1.3. (I had made copies of the files and renamed them instead of the originals. just to be sure, I have a backup...) When u're done, u can start 1.3 and it will recognize your shared folders again. Thats how it worked here. No guaranty, no warranty, no nothing, for this "guide" could also work for you too, and I also reccomend to use 1.4 and just get used to it, because new features will not be available with old releases and -most important- u have to live with all the bugs (there are a lot of them in 1.3, but I guess also in 1.4 and 1.5 and 1.6.. so its up to you...). Good luck.

Hi all, I wanted this in the 1.4-forum, but its password locked. Also, I think, it can be useful for users, which not have updated yet (and if I knew what I know now, I hadn't updated too, but waited 5 fixes) So here it comes, my very personal reaction/impression: (btw: limiting uploaded images here in the forum to only 76.8KB is quite oldschool and does not help in reporting accurately) Not the worst "update" I have seen, but definately it has a place in the top 5. After updating btsync on win7 with newest hotfixes and IE 11, it took the program about 30 mintutes to show the configured folders from 1.3. HALF AN HOUR! No popup, no instruction, that the fine little program was actually doing something. click (some screenshots are from the MAC, while I talk about Win and vice versa. I made the shots later as I installed it on several Computers...) User could think: oh my god, the update just nuked all my shared folders and panic. (Just beause of the “get started”-tooltip) click Same on Mac OSX Mavericks: (I had a CPU load of only 13%, but the Program was not responding (beachball of death), so I guessed, it is hard working…) click The User get the information, that he must start from scratch! "Oh my goodness, what a *#§$ mess” was my first impression. Again, no Popup is telling the poor little user, that the piece of software, he just updated is “converting” all his old btsync-config-files to newer ones (so that maybe his written scripts will not work anymore, because of the circumstances that there will be no file like .SyncID, .SyncIgnore anymore, but a binary identical file called ID inside a .sync folder. Which is, IMHO a care- and characterless new name, which not indicates to the sourceprogram btsync. I have seen other sync-clients, which used the same naming scheme and hopefully, I will not install them again on the same folders!) My second impression: The GUI had changed to address the less technical users (which is not a bad thing at all), but this means, all important informations is kept from the users which are interested in whats happening and keep them from simply know/see whats happening with their data at the moment. thats a trend, I can witness nowadays more and more. make things look easy, so users think everything might be good. but the software core gets complicater and confusingly and not even remotely comprehensible. Developers are forced to do things they can't (like GUI programming) and therefore they can't do good core-code anymore... well then... As usual with any big update of btsync, it crashes (Win7) on big folders a lot of times, while indexing. User (me) needs to restart btsync about a dozen times so btsync fortunately continues indexing again. Sometimes it crashes with the "microsoft runtime error", sometimes, btsync catches the crash offering to restart the programm or sent a (non anonymous, and offering a lot of very private or company related data) log file to the staff (which is mostly not sent because of some http error it reports). click, click, click The GUIs usability is....very improvable and should IMHO never relay on the systems browser, but on its own. For windows, I guess, u will earn all kinds of errors related to IE instead of btsync, like: click (means: a script is taking too long, skip or continue its execution) Also, I read in the forums, that users should reset their IE settings or secure zones to default to have the GUI work properly. ... seriously? Loose important configs just to have a independend GUI -maybe- work? hmmm. Sounds like we're back to windows98. "try to reinstall windows to use our great product and all the features will work then. we promise" Also the useful information, which file is tranfered atm is lost (or I didn't find it) but the unspecific information how long a folder transfer will take pops up, hovering over a folder in the new gui. Very useless information IMHO, because the transferes will never stop here and -as usual with any remaining time calculation-, its just wrong. Also, its very unkind to hide information off the user. (A lot of times, I need a special file transfered/synced quickly, but now I can’t even see if its in the queue or not, so I can just sit there dumb) On Mac I was aked this: click but not in *nix, neither on the Windows Platform. So I guess, I have not accepted your privacy policy on those platforms. The columns of the GUI are not really rezizable. Or even movable. It feels like a crappy implementation of something, nobody has ever tested. (no offence! but it feels so.) There are no seperators (or a very very lightly colour is used) a user needs to move the columns to the size it really makes sense for him to see important information all at once. User can move, or better rezize the columnheaders, but in a very crippled way. I seems, there was no usability in mind, when this kind of "toolbar" was invented. Also, no sorting of a column is possible. Could be very useful too. On Win7, resizing the btsync main window just gives me a black or blank window. When I rezize it back to its (way too small for any information shown) default size, I can see the (way too less) information again. Same on maximizing the main window. It keeps blank or black after an hour of waiting. Sometimes, after some crashes of btsync, it works, but then it looks like this: (over an hour waiting again) click Although its a good thing user can change the textsize (on Win, not on Mac) with the CTRL+NUM+ or CTRL+NUM- Keys, line spacing is too big. click Also the rezizing of the colums does not work with smaller textsize and still looks crappy and keeps important information off the user. The GUI behaves very very laggy (hopefuly only while indexing…). It feels like a VNC remote session back in the 90s: Klick - wait - wait - action. Klick - wait - action. Klick - wait - wait - wait - action. When the User has made some changes to the GUI that he can actually use, all the changings are lost via a new start of the GUI. thats sad. Every item is on its default position. Even the window size. very very sad. For the WebGUI on *nix system I can tell almost the same. It has glitches like closing the "view keys" section when clicking on the checkbox "Use predefined hosts". Also I just don't find a way see/generate a nicely QR-Code. Could be useful. The version 1.3 took about 1.8GB of the RAM of my *nix machine, it now takes 2.3 GB RAM for the same amount of data. The Icons for R/O shares look like the share is not accessible, but thats just my view. The History isn't really usable anymore. Its not updating in realtime after some time. It just stucks and most of the time, when the history is opened, btsync crashes. seems to me, the user shall not use the history or the developers never use it, because crashes are easily reproducable here. very easy and quick. Changes in the folder properties seem to take effect imediately, there is not OK/"Save Changes" button (anymore) in the preferences, which is also a (IMHO not so intelligent) trend (for the not so technically users) where inadvertently changes can break the whole thing without even realising the change at the moment. (but the greatly improven user feedback in the forums will show, that the procuct is widely used :-) ) All the (Web)GUIs on the different OS are lookalike, which is nice, but their behaviour seems very different from each other to me. One identical characteristic is that all GUIs are taking ages to display information: it seems to me, that information is only shown, if the indexing process (after a start of btsync) is finished. this leeds to 10-30 minutes of looking at this: click Anyways, I like the new GUI, but it really really needs some fixes, but most important for me (or the companies, i’d like to help/support with your software): I can report, that btsync continues to overwrite new data with old data, if there are several folders with >100.000 files in it and there are more than one machine with a writable secrec/key. So, in this case, btsync can mainly be used for backup or software distribution solution, but not as a data syncing tool for productive users/companies. This is mainly the most important thing, I would consider, but it seems, to have a nicely looking GUI seems more attractive to get more and more users (and helping them to erase their important data…*I am cynical atm*) The iPhone App: my old settings had the camera roll (photo) backup activated. the new version deactivated it for unknown reasons. When I try to switch it on, it crashes (no Jaillbreak, normal newst IOS 7) But, I found good things too: turning on debuging on *nix systems it now available via the webgui. no creepy terminal sessions anymore. eerm. thats all. (finally, lets not forget: this software is freely available, which means, we are the alpha/beta testers and have to spend our free (or even paid) time/life and our data to improve this product for future use. Also the developers and the forum-supporters did and do a great job fixing bugs and helping users (like me) out of their unlucky situations with a software product, written by humans like ourselfs. If we could do it better, we should!)

Hi Helpers, I was lookin for a problem with speed limits, and found some threads already describe a lot of ways to check what are the reasons. http://forum.bittorrent.com/topic/30212-download-limit-is-ignored http://forum.bittorrent.com/topic/30392-something-weird-going-on-with-rate-limiting Unfortunately, I got the situation, that the speed limit is obeyed, *although* the limit is not activated. (In other words, my limit settings are ignored) (I restarted the application, though, I tested the last weeks and realized, that restarting btsync was not needed to acativate/deactivate the speed limit (on Mac)) Now I'm using btsync 1.3.109 on MAC OSX Mavericks. my folder settings: -use relay server when required -use tracker server -search lan What I did / Steps to (maybe) reproduce: I set the limit rates to "10" and restarted btsync. => btsync limits the bandwitdh after running again. I disabled (unchecked) the limit and restarted but the limit is still the same ("10"). -> I can see the rates in the transfer tab. I then activate the checkboxes again, change the "10" to "30" and disable the checkboxes again and restart btsync and voila, the speedlimit is now on "30" (although the checkboxes are still disabled) this process took me a while, because btsync did not apply my settings every time I had restarted. I guess, there is something wrong with the speed limit feature at all :-)

++ I reconized btsyncs "faulty" behaviour some time ago, but never realized, it wasn't my fault, but a feature. I often wondered, why the transfer of the data took so damn long, when all the files i'd like to share are on another computer just next to me in the same network. (For $$ reason, we have a "small" Internet line to the world but 1GBit network inside our company.) It seems obvious to me, that "local" data needs be prefered before non-local data. Dropb*x btw. has a great feature called "LAN-Synchronisatio", which -if activated by the user- just syncs all the data in the LAN first, and then to/via the internet.

++ THIS is (would be) very useful!

Hi, 1) this is not possible, as long as I cannot anonymize them. 2) the file was not updated by me, nor do I think, it was udated by any service on the Linux or Mac Computer. I also don't think, the file was changed on the Win7 Computer, because the filedate on the Mac is 14.09.2009. This are files, I did not use since ages. (Although I cannot exclude 100%, that the Win7/Mac/Linux Computer had "touched" that file anyhow...) a) Yes, the log is form the r/o Mac folder No, the files was not deleted from the mac, nor from the r/o linux folder c) Nope, I didn't turn on the Win7 Computer, 'cause its still broken d) Ok, I see, thank you, but a rescan on the Win7 Computer can't be done, because of c) EDIT: Stupid Smileys... changed the b )

Unfortunately, it does not work for files created *after* making those changes in the .SyncIgnores and re-adding the folder. All files/Aliasses created by me yesterday night, show up again in the transfer log endlessly. I'll wait until the fix comes

Thank you. Nope! its getting even worser in the logfile (debugging turned on): I just filtered "FooBar.ext" on the Console. I also got some other debug loglines CPU on my Mac is dying and fans are on 6000rpm since I started btsync this morning (09:00), so I guess the rescan doesnt do anything helpful in my case.

This seems to do the job! (for this particular share)

Thank you. Yes, its on source Win7, but the Computer will not be up the next weeks, I guess (failing hardware), so I can't touch the file. (I feel a bit MC Hammer'ed!) anyway, on what systen do I have to do a folder rescan and *what is* a folder rescan? will the messages go away without me doing anything?

I deleted and re-added that /User/me/Documents folder yesterday and today there is no change within btsync. (only on the mac which is the source of the files) btsync is still syncing the Aliasses from the Desktop and the xls files from the Documents folder every 5-15 minutes. I will now try to put the wildcards (*com.apple....) into my .SyncIgnores on both shares.

First thank you for your thoughts and your time, but isn't this exactly the same as opening the saved log with a texteditor and doing a Search&Replace by hand? My Perl coding isn't the best, but your script-documentation is quite fine :-) So, when I have a logfile over 5 MB with, say, 500 different files/folders, will this little script help me in any way better than search&replace those 500 different files/folders by hand? I was looking (hoping!) for somewhat like an automated script which "remembers" file/foldernames which it already has replaced, so that if it finds the same file/foldername again while doing its work, it just replaces the new occurence with the old replacement. this way the developer, which looks at the anonymized log, can identify the different scenarios/lines at the log, where a file/folder has problems. If I would replace every single file/folder with a new replacement, nobody would know that the same file is mentioned in logfile line 515 and line 2626 and line 263632. so this is the reason, why I don't find time to anonymize my logfiles by hand. because I want to send you the whole logfile, not just a snippet, where the important entries may be removed by me. Any ideas welcomed! Maybe we need to create a tool like this? But I think my coding skills are not even good enough for the above example ;-/

Here's what I added some weeks ago to both .SyncIgnores: Comparing your Text and mine, they're seem identical. Beside, I don't have those * at the begining! What I don't recall, is if I re-Added the Folder again after restarting the btsync's on both machines. So I will now remove and add the said folder again. Thank you for that hint! That seems pretty fine to me :-) but, when a fixed version is out, do I have to remove those lines from all my .SyncIgnores before updating, or will they just "ignored" when found in the .SyncIgnores? I'm just asking, because I copied the above to all my .SyncIgnores because of the massive text overflow in the logfiles, which was then reduced drastically to a readable minimum. Again, Thank you!

I have similar issues with btsync on mac/win/linux Version 1.3.109 (1.3.109) [20140811 00:32:39.338] LoadTorrent: requesting to load file FooBar.ext which is modified on disk (cur:1258210018 stored:1258210017 size1:1266 size2:1266 hasInfo:0) - rejecting until file info is updatedThe source file is on a Win7 PC which is turned off since 1 Week, so the file couldnt be touched by me. The linux server has a read-only secret and the mac (where I took this Log-line right now) has a read-only secret too. On the Linux server, I couldn't find FooBar.ext in the log file. ls -la on the linux server gives: -rw-r--r-- 1 btsync users 1266 2009-11-14 15:46 /volume1/BTSync/FooBar.exton the mac, there is no such file.

Hi, I was hoping this was solved with Version 1.3.109 (1.3.109) but the problem resides. I have a source share on a Mac, which is the Desktop, living in /Users/me/Desktop. I too, have a source share /Users/me/Documents on the same Mac, which is my Documents Folder. On the Desktop I have Aliases for files in some subfolders in my Documents. Say, some files like /Users/me/Documents/company/foo/bar1/important123.xls have an Aliases on my Desktop When I change an important123.xls file, I usualy doubleclick the Alias on the Desktop, then Excel opens and I do some things and quit Excel while saving the edited file. BTSync should then recognize the change in the important123.xls file and sync it to a linux server with the same version of btsync and a read-only secret. But the syncing process never ends, or better, it starts over and over again, even though I did not change any important123.xls file for hours. Also, the Aliases are synced over and over again. Its not happening all the time, but when this is happen, the process takes an hour and the CPU of the mac is sweating while the fans are running like hell :-) This is a censored screenshot: P.S. I'd love to add a log from the mac, but unfortunately, its includes too much sensitive filenames and foldernames, so its not possible. Is there anywhere a "log-anonymizer" which just let the user anonymize the sensitive data? find&replace will take ages and I can't spend that time, i'm sorry.

Hi, I'd like to send some logfiles, but they contain sensitive names of folders and files which I don't want to, and may not disclose to anybody outside my company. Is there somewhere a tool which "anonymize" a (btsync) logfile? Say, since, the lines of a log start by a similar pattern when telling something about a special file/folder, the tool could just replace each files/folder by non-sensitive names, so developers don't loose the reference to other lines of the log, but cannot read/guess the original names. It would take ages for a human to search & replace all those files / folders (maybe server names too) by hand, so I've looked around, but didn't find any suitable. any Ideas/links? thank you.

I named a folder like "################################testfolder" so I would defintely see it in the history, but it did not show up in the log, though the file was restored. I now know that ONLY Files are shown in the History Tab. Folders are not shown. Thank you for your help.

Next Question in this reference: Is it correct, that all the files/folders, which are "restored" via the "[ ] Restore modified files to original verison"-Option, are NOT shown in the history-tab of btsync? At least, they don't show up here on the Mac Version 1.3.106 (1.3.106) (This is useful information, which I would expect in the History Tab to see.)

I would prefer the contrary 8-) The reason, I'm not concerned about the trillions of log entries: http://forum.bittorrent.com/topic/29233-bt-sync-seems-not-to-be-closing/ The reason, I don't have a Debug.log to offer: http://forum.bittorrent.com/topic/12658-if-you-have-syncapp-issue/page__st__100#entry64500

Because I have trillions of entries like: [20140708 14:59:03.437] SyncFilesController: failed to load torrent for file "/volume1/BTSync/Dir/Applications/Microsoft Office 2011/Microsoft Excel.app/Contents/Resources/de.lproj/PasswordProtection.nib/keyedobjects.nib"[20140708 14:59:03.437] TorrentFile: Failed to create empty suffix for file "/volume1/BTSync/Dir/Applications/Microsoft Office 2011/Microsoft Excel.app/Contents/Resources/de.lproj/RibbonTabData.nib/designable.nib" - 20and therefore I can't read any important information anyways, and I know the dev team is aware of this and I don't want to have my HD the whole time running/spinning cause of "useless" infos like that. IF I encounter problems that are important to me, I will turn the loggin on again.

Great News! (and important knowledge of the "invalidated" files, too) I always wondered, what the option "[ ] Restore modified files to original verison" would/could do.... Thanks!