Issue Syncing From Osx To Linux With 1.3.67


milleri

Recommended Posts

I upgraded both my Mac (Mavericks patched up to date) and my Synology (DSM 5.0) to 1.3.67.  I'm getting the following errors in sync.log, presumably failing to sync alternative streams or extended attributes.  Any advice on how to resolve?  Thanks in advance, imm

 

[20140326 11:39:43.418] Error downloading file {filename deleted}/com.apple.metadata:_kMDItemUserTags: PostDownload: hostname not found
[20140326 11:39:43.418] Error downloading file {filename deleted}/com.apple.FinderInfo: PostDownload: hostname not found
[20140326 11:39:43.418] Error downloading file A{filename deleted}/com.apple.metadata:_kMDItemUserTags: PostDownload: hostname not found
[20140326 11:39:43.418] Error downloading file {filename deleted}/com.apple.FinderInfo: PostDownload: hostname not found
[20140326 11:39:43.418] Error downloading file {filename deleted}/com.apple.metadata:_kMDItemUserTags: PostDownload: hostname not found
[20140326 11:39:43.418] Error downloading file {filename deleted}/com.apple.metadata:_kMDItemUserTags: PostDownload: hostname not found
[20140326 11:39:43.419] Error downloading file {filename deleted}/com.apple.metadata:_kMDItemUserTags: PostDownload: hostname not found
[20140326 11:39:43.419] Error downloading file {filename deleted}/com.apple.FinderInfo: PostDownload: hostname not found
[20140326 11:39:43.419] Error downloading file {filename deleted}/com.apple.metadata:_kMDItemUserTags: PostDownload: hostname not found
[20140326 11:39:43.419] Error downloading file {filename deleted}/com.apple.FinderInfo: PostDownload: hostname not found
 

Link to comment
Share on other sites

That is why I have excluded them in my .SyncIgnore on the Mac, as I am mainly syncing with FreeBSD servers for backups and do not need the xattr

com.apple.FinderInfocom.apple.metadata:_kMDItemUserTagscom.apple.ResourceForkcom.apple.metadata:kMDItemFinderCommentcom.apple.metadata:kMDItemStarRatingcom.apple.metadata:kMDItemOMUserTagTimecom.apple.metadata:kMDItemOMUserTagscom.apple.metadata:kMDItemOMUserTagTime

Since then, all shares are syncing without problems.

Link to comment
Share on other sites

That is why I have excluded them in my .SyncIgnore on the Mac, as I am mainly syncing with FreeBSD servers for backups and do not need the xattr

com.apple.FinderInfocom.apple.metadata:_kMDItemUserTagscom.apple.ResourceForkcom.apple.metadata:kMDItemFinderCommentcom.apple.metadata:kMDItemStarRatingcom.apple.metadata:kMDItemOMUserTagTimecom.apple.metadata:kMDItemOMUserTagscom.apple.metadata:kMDItemOMUserTagTime

Since then, all shares are syncing without problems.

 

Fine for you. But this is not a solution for the problem. The shared folder is shared between a lot of Macs and it is really GREAT that now all the extended attributes are really shared. But there are also some Linux servers in the share group in order to keep external backups of the data, and therefore it is really ugly, that the system is not able to handle such a situation.

 

Excluding the extended attributes is definitively not an acceptable solution.

Link to comment
Share on other sites

Excluding the extended attributes is definitively not an acceptable solution.

I concur, this is not a proper solution, so it needs to be ironed out by the BTsync devs. But for the time being, I am able to use my shares with this "quick'n dirty" solution and others might be able as well i.e. not using xattr in a mixed environment.

Link to comment
Share on other sites

I concur, this is not a proper solution, so it needs to be ironed out by the BTsync devs. But for the time being, I am able to use my shares with this "quick'n dirty" solution and others might be able as well i.e. not using xattr in a mixed environment.

 

It's an acceptable short term workaround, but it still causes ugliness on the server side in the form of lots and lots of the following types of log entries:

 

[20140326 17:17:05.476] Blocked downloading file {filename removed}/com.apple.metadata:_kMDItemUserTags due Connection closed

Link to comment
Share on other sites

It's an acceptable short term workaround, but it still causes ugliness on the server side in the form of lots and lots of the following types of log entries:

 

[20140326 17:17:05.476] Blocked downloading file {filename removed}/com.apple.metadata:_kMDItemUserTags due Connection closed

Resolved by including in .SyncIngore on all members.  Hopefully this will get resolved in the next release.  It's desirable to be able to sync extended attributes.

Link to comment
Share on other sites

  • 3 weeks later...
  • 2 weeks later...

I updated my .SyncIgnore files on my linux machine, but NOT on my Macs. Seems to be working with 1.3.94 — the Macs (presumably?) share xattr with each other, the Linux box doesn't accept them.

 

Still a workaround, but perhaps a (slightly) better one, right?

what do you mean with "updated my .SyncIgnore". What exactly have you done?

I've added the following lines to my .SyncIgnore:

 

```

# Thease entries are based on this bug:

# http://forum.bittorrent.com/topic/28625-issue-syncing-from-osx-to-linux-with-1367/

*.FinderInfo

*.ResourceFork

*.metadata:_kMDItemUserTags

```

 

This stops the sync-process but i dont now if this will break somthing.

Link to comment
Share on other sites

@JAnguita

It is not a single issue we have in BTSync. Our developers are working hard on both fixing existing issues and developing new version of BTSync. We plan to add option to disable xattr sync in future.

 

Im curious about how you'll implement that option.

 

What i want to say is: I dont know what xattr's are, and i dont want to know what it is. I'm the user. Dont make me think. An option for it sound to me like a hotfix, but not a longterm solution. At some time i want to see my whole family and friends use this app. So when it leaves the beta-status it shoudlnt concern the user with such options.

 

How about detecting OS's in the network to automate this option. Or somehow detecting conspicuous behavior in the sync-process of metadata-files. ...just some ideas.

Link to comment
Share on other sites

I confirm that adding the list shown below to the .SyncIgnore file of each synced folder (on each machine) solves most problems... until a new version fixing these issues is provided by our beloved dev team ;-).

 

However, BTsync 1.3.94 will still fail when special file names are encountered, for example a file named "Plot Kag 2F*", with a star in the name, will lead to an infinite loop and 100% CPU usage. Adding a rule in .SyncIgnore or renaming the file and restarting BTsync solve this problem.

 

For the time being, it is a good idea to Enable Debug Logging when a sync fails to determine which file/folder is raising an issue and to solve it by renaming the file or adding a rule in .SyncIgnore.

 

I just regret is that it is not possible to set a .SyncIgnore file within the iOS app.

Iconcom.apple.FinderInfocom.apple.metadata:_kMDItemUserTagscom.apple.ResourceForkcom.apple.metadata:kMDItemFinderCommentcom.apple.metadata:kMDItemStarRatingcom.apple.metadata:kMDItemOMUserTagTimecom.apple.metadata:kMDItemOMUserTagscom.apple.metadata:kMDItemOMUserTagTime
Link to comment
Share on other sites

@EddyLB

 

Actually, Sync 1.3 has a special code, intended to replace illegal characters with underscore symbol. It is surprising indeed that in your case it causes high CPU load.

 

Can you please share more details on which OSes and filesystems you sync the file with special chars? Also - is app still responsive when it gets to 100% CPU or it freezes?

Link to comment
Share on other sites

Hello @RomanZ,

 

I deleted the files "Plot Kag 1F*" about 2 days ago and unfortunately I did not keep a copy of the logs. So I re-created a file with that name from the one I renamed to solve the issue (originally a Mathematica file produced long time ago on Mac OS 9, w/o extension). BTsync now displays an Info icon in front the folder telling that it has to upload the file "Plot Kag 1F*" to my laptop (27.6 kB). I use BTsync 1.3.94 on a Mac Pro 2 x 2.66 GHz Quad-Core Intel Xeon running OS X 10.8.5. This is like this for more than an hour.

 

On my laptop, a MacBook Pro Retina 2.6GHz Intel Core i7 running OS X 10.9.2, BTsync 1.3.94 tells that this folder was synced successfully an hour ago.

 

On the Mac Pro, I find the following lines in the logs (related with this file):

...[20140514 09:05:18.592] Merge: processing get_nodes message for /[20140514 09:05:18.694] Merge: processing get_nodes message for /Plot Kag 1F*[20140514 09:05:18.965] Merge: processing get_files message with 1 paths[20140514 09:05:18.965] Merge: will send files for /Plot Kag 1F*[20140514 09:05:18.965] Merge: get_files - no entries for path "/Plot Kag 1F*"...[20140514 09:27:35.391] Merge: will send files for /Plot Kag 1F* [20140514 09:27:35.391] Merge: get_files - no entries for path "/Plot Kag 1F*"...[20140514 09:27:48.501] Merge: processing get_nodes message for /Plot Kag 1F* ...[20140514 09:48:18.658] Merge: processing get_files message with 1 paths [20140514 09:48:18.658] Merge: will send files for /Plot Kag 1F* [20140514 09:48:18.658] Merge: get_files - no entries for path "/Plot Kag ...

The CPU is not at 100% now.

I then moved the file to a non-synced folder and immediately BTsync reported that the folder was synced.

 

I then created a new folder, moved the "Plot Kag 1F*" file into it and added this new folder to the list of synced folders to launch a test  from scratch between the same machines. I got the following logs:

…[20140514 09:46:36.866] Merge: processing get_nodes message for /Plot Kag 1F*[20140514 09:46:36.949] Merge: processing get_files message with 1 paths[20140514 09:46:36.949] Merge: will send files for /Plot Kag 1F*[20140514 09:46:37.786] Incoming connection from 172.17.43.99:55388[20140514 09:46:37.786] Merge: get_files - no entries for path "/Plot Kag 1F*"…[20140514 09:46:47.842] Merge: processing get_nodes message for /Plot Kag 1F*…[20140514 09:46:47.971] Merge: processing get_files message with 1 paths[20140514 09:46:47.971] Merge: will send files for /Plot Kag 1F*[20140514 09:46:47.971] Merge: get_files - no entries for path "/Plot Kag 1F*"…[20140514 09:46:57.995] Merge: processing get_nodes message for /Plot Kag 1F*[20140514 09:46:58.331] Send ping to peer (0000000000000000000000000000000000000000) for share 889C5E25392ED651BC2945AD38D2376CC98B1F6F:[20140514 09:46:58.331] ping 172.17.200.175:23566[20140514 09:46:58.331] Merge: processing get_files message with 1 paths[20140514 09:46:58.331] Merge: will send files for /Plot Kag 1F*[20140514 09:46:58.331] Merge: get_files - no entries for path "/Plot Kag 1F*"…[20140514 09:47:08.686] Merge: processing get_nodes message for /Plot Kag 1F*…[20140514 09:47:08.791] Merge: processing get_files message with 1 paths[20140514 09:47:08.791] Merge: will send files for /Plot Kag 1F*[20140514 09:47:08.791] Merge: get_files - no entries for path "/Plot Kag 1F*"…[20140514 09:47:19.225] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:47:29.943] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:47:39.790] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:47:49.714] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:47:59.926] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:48:10.292] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:48:20.909] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:48:30.736] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:48:41.182] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:48:51.661] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:49:02.381] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:49:12.944] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:49:29.144] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:49:42.360] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:49:52.557] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:50:06.857] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:50:18.447] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:50:30.875] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:50:46.492] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:50:59.501] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:51:14.484] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:51:27.227] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:51:42.372] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:52:00.546] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:52:25.468] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:52:43.993] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:52:56.312] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:53:08.885] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:53:19.809] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:53:42.699] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:54:18.278] Merge: get_files - no entries for path "/Plot Kag 1F*"[20140514 09:54:30.451] Merge: get_files - no entries for path "/Plot Kag 1F*"...

Surprisingly, the file was finally uploaded to the laptop after spending some time with the usual message. But I kept getting these messages "no entries for path…".

 

Hope this helps.

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.