Latest Desktop Build 1.4.106


RomanZ

Recommended Posts

Dear community,

Sync 1.4.106 is now available on download site. Here is direct link. It is NOT available via auto-update yet.

Change log

- Fix crash when running binary next to settings.dat file

- Improved debug logging

- Fix issue with Sync icon not updated during switch between light / dark theme (MacOS)

- Fix out-of-sync issue (PowerPC only!)

- Fix issue with IgnoreList not working on Sync startup

- Fix issue with Sync inability to start on MacOS when user folder is moved to another drive

- Minor issues fixes

 

Important Notes on Sync 1.4
Downgrade to 1.3 is not possible after installing Sync 1.4.
(If you wish to downgrade - please uninstall Sync removing all settings, then install 1.3 and configure all folders from scratch)

Important Notes for Sync 1.3 Users
Windows XP and Server 2003 clients using Sync 1.3.x will not receive auto-updates to 1.4, but can still update to 1.4 manually.

Known issues
- UI is tiny on high resolution displays [Workaround]
- Sync may continually re-index SMB shares [Discussion]
- Renamed files are logged as New Name → Old Name (instead of Old Name → New Name) [Discussion]

- Checkboxes once selected may move out of alignment on OSX Yosemite [Discussion]

- Certain models of Android mobile devices cause deleted files to return with 0-size

Link to comment
Share on other sites

Guys,

I just downloaded and installed this (from the first link on your post) and it is coming up as V1.4.103 on the notifications bar??  On checking the direct link I see you have a properly named file - I will try this one instead, but can you PLEASE check the download site BEFORE you post its link!  yes, the one in the direct link is the new one!

Link to comment
Share on other sites

Hi All,

Just a quick note to report that I am still experiencing the incorrect 'locked file' report on GUI with this new release of 1.4.106.  It is interesting to see the known issues section omits this, the issue mentioned above and the 'out of sync' reporting(on all but Power PC's)  and the Microsoft Office incompatibility issue.  This omission leads me to ask what issues are actually on your list and what are being worked on and in what priority?  Just to be clear my meaning of issues is faults, or bugs as mentioned in a previous post of mine regarding the listing of known faults.  It would also be interesting to know what 'minor issues' actually are, as some people may need to know that a 'minor issue' has been fixed.  Its all a little vague.

Link to comment
Share on other sites

I will try this one instead, but can you PLEASE check the download site BEFORE you post its link!

The "Download site" link is always the same. There were an unexpected delay in delivering builds to download site, I apologize for that.

 

@colinabroad

1. Locked files issue is still there. The issue is cosmetic and is not planned to be fixed as part of 1.4, though is fixed in 2.0.

2. Microsoft office compatibility issue is not fixed yet, we are looking for volunteers to test the possible fix at the moment.

 

what issues are actually on your list and what are being worked on and in what priority?

In the "Known issues" section we publish issues we are asked a lot about by community members / users via support channels. The full list is huge and there is no sense to publish it here.

I also see no point in publishing the priority and issues being analyzed at the moment - this is internal information and it changes rather quickly.

 

It would also be interesting to know what 'minor issues' actually are

"Minor issues" are issues that do not affect user experience. All changes that do change Sync behavior are mentioned in change log.

Link to comment
Share on other sites

@colinabroad
 

I am assuming (perhaps incorrectly) that 1.4.106 INCLUDES whatever work you had done in 1.4.10005 ??  or have I just made a backwards step in upgrading to this version?

 

All experimental builds are side branches (i.e. they never updated with fresh fixes) and are built on top of some release build. The 1.4.10005 is based on 1.4.103 and it does not contain any fixes from 1.4.106.

As soon as 1.4.10005 proves working - we'll deliver it to maintrain (1.4.107 or above).

 

I am happy to test your possible fixes of the office issue, but need to keep my 1.4.xxx version rather than 2.0.

You already participated testing and reported results, so no need for another test. We need more reports from other users suffering same issue.

Link to comment
Share on other sites

I am having the same issue.

 

Currently running 1.4.106 on 2 Macs. They are connected via a VPN, if that matters. They became "out of sync" 4 days ago, and haven't updated since. I've tried removing and re-adding the affected share. The affected share is using a read-only secret.

 

Everything was working fine, and no changes were made, then all of sudden the syncing stopped.

 It's also a pretty large directory we are moving one-way, over 1TB.


I also wanted to add that I was running 1.4.103 before, and the issue was happening. Today I upgraded to 1.4.106 to see if the problem would be solved, and it hasn't been.


FWIW, the logs on the receiving machine say:

 

[20150114 14:23:38.472] TorrentFile: Failed to create empty suffix for file [then my filename]

[20150114 14:23:38.472] FC[61F3]: LoadTorrent: failed to load torrent for file [then my filename]

 

They say this over and over again, many times per second.

 

///

 

On the sending machine, the log reports more information, including: 

 

​"failed to open tunnel to [my ip]:[port number]:TCP"

 

and

 

"send ping to peer [hash] for share [hash]"

"ping [my ip]:[portnumber]"

API: -->getsyncfolders(discovery= then some numbers)

Link to comment
Share on other sites

I am having the same issue.

 

Currently running 1.4.106 on 2 Macs. They are connected via a VPN, if that matters. They became "out of sync" 4 days ago, and haven't updated since. I've tried removing and re-adding the affected share. The affected share is using a read-only secret.

As the affected shares are using read-only secrets, have you tried selecting the "Overwrite any changed files" option for these folders?

If so, and yet your out-of-sync issues persist, please see this post as an experimental test build is available that may address out-of-sync issues.

Link to comment
Share on other sites

Thanks. "Overwrite any changed files" did the trick.

 

I'm a little confused about how one-way syncing works.

 

Say I'm one-way syncing from directory B to directory A (obviously on different computers).

 

Directory A has been given a one-way secret from directory B.

 

After the initial sync, what happens in the following cases (my impressions in parentheses). It would be very helpful if you could verify my impressions for each scenario:

 

  • a file is created in directory A
    • (I'm assuming nothing would happen on side B, since A is setup as a one-way destination)
  • a file is created in directory A, then deleted in directory A
    • (I'm assuming nothing would happen on side B )
  • a file is created in directory B
    • (I'm assuming the file would sync to side A)
  • a file is created in directory B, then deleted or moved in directory A (if moved, moved fully out of the sync folder on side A)
    • (I'm assuming the disappearance of the file [ie. either moving or deleting it on side A] would not sync back to side B – but would the status indicators for each directory now become inconsistent? In other words, in my testing I noticed that side A has the green checkmark (aka in sync) and side B now says Out Of Sync. If my assumption is correct, why doesn't side B notice the file is gone, and try to re-sync it back to side A [regardless of what side A did to make that file disappear])?
  • ​a file is created in directory B, then moved in directory A (to a new folder that had been created on side A, never reflected in side B, but still within the sync folder of directory A)
    • (Same outcome as the previous scenario? The deletion would not sync back to side B, but now side B sees that file no longer exists in side A, so wouldn't it try to copy it back to side A to restore consistency/sync.
  • a file that exists in B and A is renamed on side A
    • (side B sees that the file no longer exists on side A [because it has been renamed] and syncs the file back over to side A, leaving you with a re-named copy, and the copy that B just sent back to A.)
  • ​a file that exists in B and A is deleted on side B
    • (The file is deleted on side A, in accordance with one-way sync)
  • a file that exists in B and A is moved on side B (moved totally out of the sync directory)
    • (The file is deleted on side A)
  • a file that exists in B and A is moved on side B (moved within the sync directory)
    • (The file on side A is moved to the same location)
  • a file that exists in B and A is renamed on side B
    • (The file on side A is renamed)

 

Given my above A/B scenario, could you explain "Overwrite changed files" in context and perhaps a bit more detail? I understand that the option is only present on a "read-only" node.

 

"Read Only" in the context of Bit Torrent Sync is a bit strange to me. If side A is "read-only", intuitively I would think that B could only read from side A, but instead it means that B can write to A, and A can't write to B. I find myself always having to pause and really think through how this works, every time. True?

Edited by otacon
Link to comment
Share on other sites

@otacon

First of all, the terms "Read-only" and "Read-write" peers determine what the peer can do to others. If it is read-write - it can both get and deliver data. If it is RO only - it can only read data, but will never propagate changes.

 

There is a rather simple rule to determine RO peer behavior. When "Overwrite..." checkbox is not checked. RO peer is getting all file / folder updates from other peers. Once some file is deleted / moved / modified on RO peer - it will never be updated anymore. Of course, the very fact of file change also won't propagate.

If you check the "Overwrite..." checkbox in folder preferences - RO peer will discard all the changes (modifications, movement, deletion) and re-sync file from RW peers.

 

Hope it helps.

Link to comment
Share on other sites

Unfortunately, I had to uninstall and move to a different tool due to the 0 byte issue.  it was happening way too often and causing major disruptions.

 

I do know we used the builtin upgrade under preferences, so I struggle to understand how mixed architecture versions were installed unless there is a bug in the upgrade tool.

Link to comment
Share on other sites

That was the first thing I checked. Only the x64 version is installed. x86 was installed previously, I have been using btsync for well over  a year, before x64 was an option.

 

It seems odd that this does not affect 1.4.103 but it does affect 1.4.106 if there is old info in the registry. If the registry is pointing to the old x86 version there is nothing there.

 

Tell me what to clean out of the registry and I will uninstall, clean the registry and re-install.

Link to comment
Share on other sites

I just swapped between version 1.4.103 and 1.4.106 and checked the registry for both the admin user that I used to install the software and the normal user. I have verified that the normal user has to enter an admin password each time btsync starts with version 1.4.106 but only the first time with version 1.4.103.

 

I found the key that you mentioned above in the registry for the admin user but not for the normal user. This is true for both versions. I have not added the key to the normal users registry since it does not appear to have anything to do with this problem since it's missing from both versions.

 

Here is what I found in the registry.

 

Admin

--------

 

1.4.103

 

[HKEY_CURRENT_USER\Software\BitTorrent\Sync]
"Revision"=dword:01040067
"extContextMenu"=dword:00000000
 
 
1.4.106
 
[HKEY_CURRENT_USER\Software\BitTorrent\Sync]
"Revision"=dword:0104006a
"extContextMenu"=dword:00000000
 
Normal User
-----------------
 
1.4.103
 
[HKEY_CURRENT_USER\Software\BitTorrent\Sync]
"extContextMenu"=dword:00000000
"ShellMenuEnable"=dword:00000001
 
1.4.106
 
[HKEY_CURRENT_USER\Software\BitTorrent\Sync]
"extContextMenu"=dword:00000000
"ShellMenuEnable"=dword:00000001
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.