RomanZ

Latest Desktop Build 1.3.87

Recommended Posts

Sorry but the problem with .Conflict is still existing - updated to 1.3.87 - all Folder with german "Umlaute" like "ä ö ü..." were duplicated in .Conflict Folders - here´s a screenshot, only some minutes old (synching between three Macs 10.9.2 using BTsync 1.3.87)

 

2005ncj.png

Share this post


Link to post
Share on other sites

JSommer,

 

Could you please:

 

1) Make sure that BTSync updated to 1.3.87 on all of your peers

2) re-add sync folders, containing umlaute characters

3) see if the issue is gone

 

I suspect that your DBs now contain invalid characters, that's why you still see .conflict folders.

 

Thanks!

Share this post


Link to post
Share on other sites

In this new version, btsync doesn't stop syncing anymore - it keeps syncing the files com.apple.ResourceFork and com.apple.FinderInfo over and over again. (I have sync set up between two macs and a linux server). Any ideas?

Share this post


Link to post
Share on other sites

 

BTSync can't sync mac's xattrs to your linux machines. Add them to .SyncIgnore on your Mac machine.

 

Roman,

 

Could you clarify this statement? Does this mean that two Mac peers cannot sync xattrs to each other if there is a Linux computer (or possibly any other non-Mac OS) as a peer?

 

If so, that's kind of disappointing. I would have hoped there would be a way for the Macs to sync xattrs to each other while the other OS's simply ignore them. For this to be compatible with .SyncIgnore, I guess the ignore file would need to work in the opposite way that it currently does--i.e. it would need to filter files from being synchronized to the peer on which it resides rather than filtering files synchronized to other peers. Maybe btsyc itself could be modified to improve the handling of xattrs?

 

Thanks!

Share this post


Link to post
Share on other sites

michellelynngill,

 

If you have 3 peers, 2 Macs and 1 Linux - Macs will sync xattrs successfully. But they will fail to sync their xattrs to Linux machine. There is a certain limitation on Linux PCs how xattrs should be named, so Mac names for xattrs does not conform Linux demands.

 

Windows should accept Mac's xattrs with no issues, if files are hosted on NTFS partitions.

Share this post


Link to post
Share on other sites

I have a problem with this version on linux debian jessie.

When i access the webinterface, I see version 0.0.0 and no shares.

 

But when i access the webinterface on my other machine with debian 7, which works fine, I can see the shares on the first machine.

Share this post


Link to post
Share on other sites

If you have 3 peers, 2 Macs and 1 Linux - Macs will sync xattrs successfully. But they will fail to sync their xattrs to Linux machine. There is a certain limitation on Linux PCs how xattrs should be named, so Mac names for xattrs does not conform Linux demands.

 

Thank you for the clarification, RomanZ. Could you explain then why you suggested adding the xattrs to the .SyncIgnore file of the Macs? Based on my understanding of how .SyncIgnore works from the manual, this action will keep the Macs from synchronizing the xattrs with each other (in addition to preventing them from synchronizing with Linux). 

 

Thanks again!

Share this post


Link to post
Share on other sites

knireis,

 

It looks like the btsync on first machine is up and running (as you see it as connected device on another), so this looks to be an issue with WebUI only. Could you please try to access to webUI from a different browser (or just clean up all cookies)?

 

michellelynngill,

The advise was going initiallty to Roza, who seems to have only 1 mac and 1 linux machine. In such setup it always better to ignore xattrs on Mac machine. If we do so - both PCs will show as synced when they finished transfer. If we ignore xattrs on Linux machine, when sync complete Mac will always show that it wants to upload some data to Linux (which equals sum of all xattrs not synced).

 

As you still want to sync xattrs between your Macs - of course, you have to modify ignore list on Linux machine (we recommend syncignore to be the same on all PCs, but in your case that will bring to a loss of some functionality).

Share this post


Link to post
Share on other sites

 

The advise was going initiallty to Roza, who seems to have only 1 mac and 1 linux machine. In such setup it always better to ignore xattrs on Mac machine. If we do so - both PCs will show as synced when they finished transfer. If we ignore xattrs on Linux machine, when sync complete Mac will always show that it wants to upload some data to Linux (which equals sum of all xattrs not synced).

 

As you still want to sync xattrs between your Macs - of course, you have to modify ignore list on Linux machine (we recommend syncignore to be the same on all PCs, but in your case that will bring to a loss of some functionality).

 

 

I understand now--thank you for the clarification!

Share this post


Link to post
Share on other sites

knireis,

 

It looks like the btsync on first machine is up and running (as you see it as connected device on another), so this looks to be an issue with WebUI only. Could you please try to access to webUI from a different browser (or just clean up all cookies)?

 

 

Cleaned the browser cache and cookies. I see 1.3.87 but no shares, after 5-10 minutes back  to 0.0.0 and no shares

Share this post


Link to post
Share on other sites

If you have 3 peers, 2 Macs and 1 Linux - Macs will sync xattrs successfully. But they will fail to sync their xattrs to Linux machine. There is a certain limitation on Linux PCs how xattrs should be named, so Mac names for xattrs does not conform Linux demands.

In the API, the BTsync node's OS can be identified. This information could surely be used to discern between xattr supporting and non-supporting OSes and make the syncing behaviour change accordingly.

Share this post


Link to post
Share on other sites

knireis,

 

Is this something new or you experience the same issue before?

If this is new issue - what is the previous build you were using which had no issue?

Share this post


Link to post
Share on other sites

yes it is new

 

knireis,

 

Is this something new or you experience the same issue before?

If this is new issue - what is the previous build you were using which had no issue?

yes it is new, it occurs on both chrome, firefox and my android tablet.

1.3.86 was fine

it happens on my server with debian jessie, not on another server with stable debian

 

the funny thing is when i restart btsync, it initially shows 1.3.86 with the shares, then a refresh of the page gives the 0.0.0 with no shares.

 

I use tuxpoldo's server package, maybe his jessie package is corrupted or something

Share this post


Link to post
Share on other sites

knireis,

 

Is this something new or you experience the same issue before?

If this is new issue - what is the previous build you were using which had no issue?

 

I want chime in on this one, not sure how relevant, but I've actually experienced similar issue when I have had one instance of WebUI open on one tab, and when I open another instance from WebUI from different server and it happened to be from localhost (for example, if I open local copy of WebUI on localhost:8888, then SSH port forwarded copy of WebUI on localhost:8889, latter one would display nothing but 0.0.0 and blank shares.

 

This particular case was existed as far as I can remember, from 1.2 era.

Share this post


Link to post
Share on other sites

1.3.87 is still crashing for me after some time on FreeBSD. I'm somewhat of a novice w/ FreeBSD so please let me know the specific commands to grab any logs / dumps you need to help solve. Thanks!

Share this post


Link to post
Share on other sites

unsignedint,

 

Could you please open a web developers console (javascript console - depending on your browser) and send me what is happening in console? It looks like javascript can't connect to the core.


@hungarianhc,

Do you see the <PID>.core file in btsync directory (or in .sync subdir)? If yes - please provide the file to me. Thanks!

Also, can you please share the details of your setup / environment so we can try to reproduce your crashes in the lab?

Share this post


Link to post
Share on other sites

@hungarianhc,

Do you see the <PID>.core file in btsync directory (or in .sync subdir)? If yes - please provide the file to me. Thanks!

Also, can you please share the details of your setup / environment so we can try to reproduce your crashes in the lab?

I don't see a *.core file. Extensions that I see in the .sync sub include *.pid, *.zip, *.log, *.log.old, *.dat, *.db, *.db-wal, *.db-shm ~ When I do a "find *.core" command, I get zero results.

 

In terms of my setup, I'm running this in a FreeNAS jail on FreeNAS 9.2.1.3-RELEASE.

Share this post


Link to post
Share on other sites

Hello,

i've updated from 1.2.91 (or somethng like this) to 1.3.87.

On windows 7, it's not reponding major of the time...

Seems to be running, but i can't acces on the screen, it's not responding.

On mac everything's ok. I've a lot og Go and folders and everything is re syncing after updated.

Share this post


Link to post
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.