Latest Desktop Build 1.4.93


RomanZ

Recommended Posts

Dear community,

 

Sync 1.4.93 is now available on download site. Here is direct link. It is also available via auto-update.

 

Change log:

  • Fixed issue with listening port randomized when changed
  • Fixed minimum window dimensions
  • Fixed status behavior
  • Fixed link validation mechanism

The change log for the previous build (1.4.92) may be found here.

 

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]
- Files containing non-ASCII characters in their names may not sync

- Files may become "Out of Sync" in certain instances (See this thread)

Link to comment
Share on other sites

Hi, this is my 1st message in this forum.

 

I created a login just to ask something really important to me and almost everyone who lives in Brazil / speaks portuguese.

 

In this topic is written:

 

"Known Issues in 1.4.92: (...) - Files containing certain characters in their names (such as accented letters) may not sync"

 

Is this issue solved? It can just broke every backup/sync system I've installed until today...

 

PS: I am using bittorrent sync as a sync plataform to my personal and business needs, and suggesting it to several friends. Read about this issue send a chill down my spine.

 

[ ]s

Dario

Link to comment
Share on other sites

RomanZ, on 17 Oct 2014 - 4:42 PM, said:snapback.png

@juggler

It is still there. We'll fix it soon.

 

@eltopo

We'll take a look on what happens, thanks for reporting.

 

@Devonavar

Sync 1.4 should handle gracefully any xattrs it can't save on target peer. They are saved into .sync folder and PC which is unable to store them as xattrs / alt streams will still be able to sync them to other machines.

 

@richdotward

Every Sync release is verified by QA. Though, there are certain limitations:

1) As Sync supports a wide variety of platforms and configurations, it is impossible to check every possible configuration.

2) We cannot include every and other bug reported by users due to limited man force.

 

For the blank UI issue - please take a look at this topic, it might help.

 

@hurik

Yes, it is.

 

@zeropluszero

We are are working on the fix to make ignoreList working very early on file change, so it should resolve your issue.

 

Unfortunately, the 1.4.93 doesn't fix the sv$ temporary file issue ;(

Link to comment
Share on other sites

I noticed that my Windows (7 and 8.1) btsync client (1.3.109) popped up "new version available" message box for 1.4.92 and 1.4.93. However, my Linux (arm) clients (1.3.109) still think themselves up to date. The Linux clients are started with --config, my configure files have the line

"check_for_updates" : true,

 

So my question is, is this new version notice only turned on for Windows clients?

Link to comment
Share on other sites

I have a list of files that won't sync now. They all start with -$ and then a filename. I don't see these files in the folder btsync thinks they are in. I have no open files, so that's not the issue. Is this part of the known bug where filenames with certain characters don't sync?

 

It seems that overall this version is slightly better than .83, but still buggy. One peer reports that it is fully synced and the other lists files awaiting transfer. Sizes are still misreported on some folders. Some folders show a size of 0. Thanks for making this version a little better than the last version of 1.4, but 1.4 overall seems to be a drastic step backward. Why did the sync engine get so buggy just because the front end chagned? Shouldn't the UI be independent of the backend? I still have high hopes for btsync (nothing matches the speed), but I currently have 0 confidence that I my data is correctly syncing across all the nodes.

Link to comment
Share on other sites

I have a list of files that won't sync now. They all start with -$ and then a filename. I don't see these files in the folder btsync thinks they are in. I have no open files, so that's not the issue. Is this part of the known bug where filenames with certain characters don't sync?

 

It seems that overall this version is slightly better than .83, but still buggy. One peer reports that it is fully synced and the other lists files awaiting transfer. Sizes are still misreported on some folders. Some folders show a size of 0. Thanks for making this version a little better than the last version of 1.4, but 1.4 overall seems to be a drastic step backward. Why did the sync engine get so buggy just because the front end chagned? Shouldn't the UI be independent of the backend? I still have high hopes for btsync (nothing matches the speed), but I currently have 0 confidence that I my data is correctly syncing across all the nodes.

 

What you described with your files containing $ sign could explain why i cant add some extension "*.sv$" in the ignorelist !

Let's hope this is actually a known bug indeed :)

Link to comment
Share on other sites

Hi,

 

I tried to (unsystematically) "test" syncing with 1.4.93. My first attempt:

 

Files like Österreich.txt, übel, öööäääüüü.txt, ÖÖÖÄÄÄÜÜÜ, dont get synced, if I store them on Debian6 and look at the files at Windows 8.1.

 

The Good thing:

 

The problem seems to disappear, when I add a non-umlaut as the first letter.

 

aöü.txt, aÖsterreich.txt aöööäääüüü.txt aÖÖÖÄÄÄÜÜÜ.txt gets synced.

 

The bad thing:

 

Filenames like bÖ.txt, aübel.txt don't work.

 

Testing is a little bit time-consuming, because I cannot force the sync process (klick a button and see, what works and what doesn't work).

 

It's nearby to ask, why there are no such standard-test cases at Bittorrent afer a year or so of development, but I don't will ask because I can imaginge the complexity of testing.

 

Edit: As I have seen soon, this problems seem to be already descovered in 1.4.92.

 

Why do you release a new version 1.4.93 of a syncing software, knowing, that files like "Österreich.txt" don't get synced? (Don't tell me something about "beta" or so, please.)

 

(The good thing is, that you tell known issues.)

 

Greetings,

 

merlinuwe

Link to comment
Share on other sites

OK, I just upgraded both my peers and now one is saying out of sync with the other, but the other is saying synced? The first one says no peers online to receive 202.28Kb, yet it can see the other peer? It seems for every step forward we are getting two step back with this software. I have changed nothing on any setting foe either computer, just closed the program and installed the update?
Once again though, it is the GUI reporting incorrectly, as the last files added and edited on the 'Master peer' have propagated them across to the other peer, I just checked. So WHY can the GUI not get its reporting of events correct??? Trust is lost with this and it is not possible to rely on this software for either backup or syncing.


@sfmcnally - I had this exact same behaviour in the past - take a look in the sync not completing thread. I did not find the cause or a solution apart from removing a third peer from my mesh.

 

@all - update on reported issue - the 202kb of files reported as requiring sync to a peer that was unavailable were only five random files - three .pdf and two .STEP 3D files, so I simply renamed them on the main PC (they were already correctly copied to the peer) by adding a minus sign into the names and as if by magic they disappeared from the queue and were renamed on the peer correctly - resulting in a full sync again.  Why is this happening??  Why pick random files and declare them unsyncable when they have clearly already been synced?  Why can they be synced with a simply name change?  No GM & RomanZ I changed NOTHING else, just upgraded the software.  It was the software that got it wrong, NOT me doing anything.  And sorry, logs won't help with this as I have fixed it now.  The maintenance required to ensure a full sync has been done and no files are being backwardly propogated from an old copy is quite high - and I only have two folders on two machines that only I am changing - lord only knows how system administrators can handle all these errors being created by the software!

Edited by colinabroad
Link to comment
Share on other sites

Would it be possible to make it default to NOT use a tracker/relay server? I can only see in the config file to do it together with all the shares, but then I would disable the gui according the comments :(

Bit annoying that when I add a folder I have to uncheck those afterwards.

Link to comment
Share on other sites

The size of data to sync is still reported wrong. Heck, I have one sync where it says it's out of sync one one node and synced on the other, but the one that says it's not says it still needs to receive 16 GB of files! All the files are synced and that's about a third of the folder size! Other than that and it not syncing the files with foreign characters it's working just fine so far

Oh and when no peers are online besides my nas it will say that no peers are online to receive some bogus number of files like 17000 GB

Sent from my SCH-S738C using Tapatalk

Link to comment
Share on other sites

@daishi4u

At last someone else is reporting the problems I have been having. Again look in the 'sync not completing threads - this is NOT only on 1.4.93, it has been prevalent for a while.  I sent in logs a while back to no avail, but I have removed the problem by removing the third of my peers, but it seems you only have 2?  With .93 running on two peers all seems OK for me - see edit on my previous post about fixing the 'out of sync, no peers available' issue I had.


@RomanZ - could you please explain what the 'fixed minimum window dimensions' statement actually means?  I am still unable to make the window small (I only have two lines of folders and so have an awfully big amount of real estate under these that I would like to squash down)  and the share and three dots menu still get obscured when sliding the right hand side of the window to the left. In fact why are these two features hidden until one hovers over the line ?  Surely having the menu bar not hidden would be better?  I don't see the three dots (copied from android I suspect) hidden on any other app/program I have used?  Another interesting aspect of this is that when touching the folder line with my finger it is highlighted and stays highlighted, yet when clicking the highlighted line with my mouse nothing changes - so using a mouse does not keep the highlighted line highlighted, so the menu and share disappear as soon as the pointer leaves the line.  Surely a touch to the screen and a click with the mouse should do the same thing?  This is on a Win8.1 Touch screen machine.

Link to comment
Share on other sites

@RomanZ - could you please explain what the 'fixed minimum window dimensions' statement actually means? I am still unable to make the window small (I only have two lines of folders and so have an awfully big amount of real estate under these that I would like to squash down)

In earlier 1.4.x builds, the minimum width you could reduce the UI window to was >768 pixels. As such, those using screens smaller than 769 pixels wide (i.e some Windows tablets in portrait orientation, etc) had the UI window overflowing the width of the screen with no way to reduce the width. In 1.4.93, the UI window can be resized to a minimum width 768 pixels. From what I can tell, however, the minimum height you can reduce the window to hasn't changed.

 

In fact why are these two features hidden until one hovers over the line ? Surely having the menu bar not hidden would be better? I don't see the three dots (copied from android I suspect) hidden on any other app/program I have used?

That's a fair point - and I agree, it would be much better to have the "Share" and "Three Dots" icons always visible on each row in the UI rather than just appearing on "mouse over" (this becomes especially important on touch-enabled devices)

 

Another interesting aspect of this is that when touching the folder line with my finger it is highlighted and stays highlighted, yet when clicking the highlighted line with my mouse nothing changes - so using a mouse does not keep the highlighted line highlighted, so the menu and share disappear as soon as the pointer leaves the line. Surely a touch to the screen and a click with the mouse should do the same thing? This is on a Win8.1 Touch screen machine.

The "row highlight" you refer to when you "touch" a row is the same affect as if you "mouse over" a row. The the current row remains highlighted as long as the mouse remains over it - this is essentially the same as a touch action - i.e. "touching" a row moves the mouse cursor to the current row where it remains in the same fashion a "mouse over" would.

Link to comment
Share on other sites

Since version 1.4.9x the web ui on FreeBSD does not seem to work any longer on the default port 8888. Any thoughts on this?

 

EDIT: I tried lynx on the console of the FreeBSD server running btsync and was able to get a connection with cookie prompt on 127.0.0.1:8888 (no UI though), but no connection on that port for the external IP.

Link to comment
Share on other sites

Since version 1.4.9x the web ui on FreeBSD does not seem to work any longer on the default port 8888. Any thoughts on this?

 

EDIT: I tried lynx on the console of the FreeBSD server running btsync and was able to get a connection with cookie prompt on 127.0.0.1:8888 (no UI though), but no connection on that port for the external IP.

Did you read "README" in the package (which you should have done for every new release)?

Link to comment
Share on other sites

@dariomor

Unfortunately the issue is still there. I've added the known issues to the topic starter.

 

@hurik

Sync uses HTTP by default when accessing linux WebUI. To use HTTPS you'll need to configure certificates. For the feature request - yes, i've seen it. We periodically browse feature requests to include some of them into release. Can't promise if / when we'll add .crt

 

@robson.sobral

Auto update enabled for 1.4.93 now for all OS (except WinXP / Win2003)

 

@speedy48

Try turning off Simple Mode - you'll be able to save received folders to whatever location you need.

 

@firminmaillard

Fixed FreeBSD x64 link.

 

@eltopo

Update turned on for everyone. Just tested my Raspberry PI - it shows the notification that update is available.

 

@sfmcnally

Just tested in my lab - no issues syncing -$abc.txt file. Most likely we'll need debug logs to find what happens on your PC. Also, fronted and core are developed separately. I understand that new UI draws a lot of attention to it, but it does not mean that core did not change.  There are plenty of changes in the core as well, and core issues are not bound to new UI.

 

@merlinuwe

No need to test, I confirm issue reproduction in my lab. We need to release 1.4.93 as it contains number of fixes demanded by users. We cannot include all the fixes we want to 1.4.93, therefore some has to be postponed.

 

@daishi4u

How do you calculate the size reported? Note, that Sync does not include it's own service file in .sync subfolder (including Archive).

 

@nils

The "Sync now listens only loopback interface" change was introduced in 1.4.82 - and was mentioned in the change log.

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.