Latest Desktop Build 1.3.94

[RomanZ]

Please see build 1.3.94 here.

 

Changelog:

 - Various crashes fix

 

The build is also published to the auto-update.

 

Previous build change log.

[tuxpoldo]

Thank you! Linux packages updated accordingly.

[mbi]

Please see build 1.3.94 here.

 

Changelog:

 - Various crashes fix

 

The build is also published to the auto-update.

 

Previous build change log.

 

The auto-updater had a much longer changelog, and IIRC it stated that the bug with extended file attributes on Macs was fixed. Is this the case? I just tried to remove "com.apple.FinderInfo" and "com.apple.ResourceFork" from my .SyncIgnore file, but those files still aren't properly synced between my Mac (1.3.94) and my rPI (1.3.93 Debian package).

 

Am I missing something?

Thank you.

[RomanZ]

@mbi

 

The change log I publish on forum is always comparing to previous published version.

I.e. 1.3.94 topic has only changes comparing to 1.3.93.

 

The auto-updater change log contains changes comparing to previous version published on auto-update.

[19feet]

Works fine on many Linux Systems with Ubuntu 14.04 64bit, Ubuntu 12.04 32bit (all with debian desktop gui) and a Fedora 20 System. Thanks to all developers including the developer for debian desktop gui. I'd like to see such a desktop gui for fedora, too.

[cubik]

WARNING:  hey team just be aware that if you're using .syncignore to exclude files in a case similar to mine, where after I have a successful sync to a media server temp directory, I then MOVE them into a live source folder which then triggers the two-way sync to remove the contents back home, you may have a problem during the upgrade...  the entire time my computer was showing the 'update to new version' window, the .syncignore file was being IGNORED which meant all my other folder content was synced up, and MOVED and then DELETED back home.  Luckily I have the syncarchive enabled on the home folder... it only happened in between when the update dialogue was on the screen, and when I actually performed the update..... anyone notice this??  be aware, then again, nothing you can do at this point... I highly suggest leaving auto update off and performing them manually in case this happens again.

Windows Server 2008 Enterprise 32bit, 1.3.91 > 1.3.94

ps.  bitsync is absolutely amazing and I love it!!!

Edited May 6, 2014 by cubik

[tuxpoldo]

Thanks to all developers including the developer for debian desktop gui. I'd like to see such a desktop gui for fedora, too.

 

Thank you! The GUI itself runs on any Linux with the dependencies installed (there are Packages available also for Arch-Linux) , but currently I have no clue how to create an RPM package. Some time ago I asked if someone would take over this task, but noone was really willing to do the work :-(

 

Does anybody here have some real life examples of packaging sources for complex applications? In Debian it's simple: you can get the source of a program including the packaging collaterals with the command:

apt-get source <packagename>

Then you can look into the debian subdirectory and learn a lot of things (beside of the excellent guides available)...

 

If you search for RPM packaging examples via google, you find only beginner shit (like "How to install your "Hello World"-console program")

[KerberosDY]

Upgrade 1.2.91 > 1.3.94 w7x86 w7x64 machines do not see each other. Downgrade 1.3.94 > 1.2.91 all works

 

ps asked to add to the proxy settings and encryption to avoid traffic fltratsii torrent

[eazq]

it seems 1.3.94 can't handle different speed links for the same share. It runs at the lowest speed. It seems high speed LAN links are not learned.

[RomanZ]

@KerberosDY

Can you share more details about your peers that do not see each other? Are they in LAN or connected over Internet? In any case, debug logs are highly appreciated.

 

@eazq

If several peers are available - BTSync benefits from both of connections getting data from both peers (until download bandwidth allows). Could you please describe your scenario, what do you see and what do you expect to see?

 

@cubik

Do I understand correctly that at the end of day you get:

 - a synced folder on 2 peers

 - some data is unique to peer A, some - to peer B (due to .syncignore - as designed)

 - you start the auto-update, and during auto-update .syncignore is not counted anymore

 - which forces unique data to be synced between A and B

 - and after upgrade the unique data gets deleted?

Please correct me if i'm wrong.

[eazq]

@RomanZ

 

• site1: WAN1
  • replica1: LAN
  • replica2: LAN
  • (replica4: LAN)
• site2: WAN1, WAN2
  • replica3: LAN
  • (replica4: LAN)

 

replica4 is a laptop. What I see is:

 

• connect replica4 to site2's LAN (wired 1Gbps);
• add large file to replica3;
• replica4 synchronizes in minutes from replica3;
• slow synchronization begins to replica1 and replica2;
• move replica4 to site1 and connect to site1's LAN (wired FastEthernet);
• replica1 and replica2 can see replica4 (LAN discovery enabled)
• replica1 and replica2 go on synchronizing the large file from replica3 (slow speed) instead of getting it at full wire speed from replica4

Edited May 7, 2014 by eazq

[RomanZ]

@eazq

 

Thanks for detailed description. It is not designed behavior. By design, replica1 and replica2 in your sample should get file from both replica4 AND replica3.

 

I wonder, when your laptop (replica4) is connected to site1 - and you put some file to it, does it use LAN connection to transfer it to replica1 and replica2? Is LAN connection used by BTSync in general when your laptop is in site1?

[emailpros]

1.3.94 crashing constantly on Windows 2012 R2. I have installed versions 1.3.6X all the way up to version 1.3.94 and they all crash. What was the last working version befroe 1.3?

Edited May 8, 2014 by emailpros

[emailpros]

Nevermind, I found 1.2.92 to not crash.

[eazq]

@RomanZ

 

Assuming replica1, replica2, and replica4 are in site1.

 

replica1 and replica2 actually list three peers each, but nothing is transferred from replica4. Both show delta is not empty and even the large file is listed in the detail view of delta, but file is actually never transferred from replica4.

 

Yes, if I add a file to replica4 it is transferred immediately to replica1, replica2 and, slowly, to replica3.

[nickluck]

Hi,

 

I see a weird behaviour in my setup.

I am synchronizing files between 3 computer.

The source pc (A) where original file are is connected via internet (with slow upload speed) to the other PCs

the two receiver (B and C) are in the same LAN.

 

What happens is: A transfers the same files twice (once for each dest PC) wasting way too much time (consider I'm transferring 10 to 20 GB over a 640Kbit line) but B and C don't share their part with each other.

The receivers show they have data to upload or download from each other but don't transfer anything.

Restarting BTSync on B (I don't have control over C) triggers the transfer of data between B and C until all available data is shared. At this point they only use A as source and never resume the sync between themselves (unless I restart BTSync again).

This is really annoying because it almost doubles the amount ot time needed to send files.

 

EDIT: I have to correct. I have checked on B and it shows it only has data to upload but it is unaware of data to be received (until restart). I guess the same happens on C (but I can't check)

 

I have attached what I see on B after leaving it running for ~1 h (line 1 is C, line 2 is A) and what I see after restarting BTSync.

 

Nicola

[masterkain]

I'm observing weird behaviour too with 1.3.94.

 

3 clients, all Mac, running the latest version, 1 ubuntu server running the latest version.

 

2 days ago I rebuilt the server from scratch, and installed btsync on it, added our folder and it starts syncing.

 

currently the sync it's still not over: btsync on the server keep requesting files that it already has in chunks of 1.7MB.

Edited May 10, 2014 by masterkain

[Udon]

I have five Macs and two Linux machines running the build 1.3.94. Similarly to nickluck's case the Macs suddenly decide to start resyncing (sending) random files. However the receiving end might not be receiving.

 

I also have close to a hundred cases of com.apple.FinderInfo and com.apple.ResourceFork just hanging and not syncing.

[Native Advertisement]

I have five Macs and two Linux machines running the build 1.3.94. Similarly to nickluck's case the Macs suddenly decide to start resyncing (sending) random files. However the receiving end might not be receiving.

 

I also have close to a hundred cases of com.apple.FinderInfo and com.apple.ResourceFork just hanging and not syncing.

 

I have a similar issue. Sync is just looping through about 4,000 com.apple.ResourceFork files, whenever it reaches 0, the number is being reset.

[RomanZ]

@eazq

replica4 should seed the file to 1 and 2. 

I need logs set to full debug output. When you bring back replica4 to site1 and it does not share it's data to replica1 and 2 - give it couple of minutes to populate the log, then collect logs from 1 and 4.

 

@nickluck

Same here. I need debug logs from 2 machines that does not sync. 

 

@masterkain, @Udon, @Native Advertisement

Apple's xattrs could not be synced to your Linux machines - linux does not accept them. I suggest adding xattr names to .syncignore to avoid such issue.

[eazq]

@RomanZ

 

Three out of four replicaX use Windows 7 x64. I compared how SQLite files with replication metadata ara manged and it appears there's a bug, or there've been one in the past and current 1.3.94 does not cleanup its environment when it starts. In replica4, there were some secret.db-wal and secret.db-shm which persisted after btsync.exe was shut down. I tried starting it up again, then shutting it down again. Those files where still there. I moved them out of the original folder, then run again btsync.exe and synchronization was back at original speed when replica4 was connected to site1. I shut it then down again to verify that only secret.db files persisted.

[tyrons]

Hello! Will this version be available on NETGEAR store?

[Udon]

@masterkain, @Udon, @Native Advertisement

Apple's xattrs could not be synced to your Linux machines - linux does not accept them. I suggest adding xattr names to .syncignore to avoid such issue.

 

Sure but I hope this will not be the final way to solve this issue. Couldn't the Mac version just refrain from trying to push those to non-Mac systems?

[Moe]

Sure but I hope this will not be the final way to solve this issue. Couldn't the Mac version just refrain from trying to push those to non-Mac systems?

Nah. Then BitTorrent Sync would have to let other shares know what client type it is and maybe some people don't want that information published

[RomanZ]

@eazq

These are SQLite service files (journal, etc). Technically, SQLite should remove them once the connection to the DB is closed (= you close the BSync legitimately).

Do I understand correctly that after you cleaned up temp files - now db-wal is removed when you close the app?

 

@Udon

Sure, this is not the final way. It is a workaround for now - it is going to be changed.