• Content Count

  • Joined

  • Last visited

  • Days Won


About BeTheSync

  • Rank
    Advanced Member
  • Birthday 01/15/1969

Profile Information

  • Gender
  • Location
    Germany, Cologne
  1. 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) )
  2. @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...)
  3. 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 :-)
  4. 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.
  5. 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.
  6. 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!)
  7. 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. 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 :-)
  8. ++ 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.
  9. 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 )
  10. 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
  11. 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.
  12. 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?
  13. 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 (* into my .SyncIgnores on both shares.