xminer

The answer regarding the question marks now seems obvious. I didn't realize the Windows file system was still stuck in the 90's. question marks are not valid in Windows - Linux and OSX allow them. BUT... That still doesn't explain why files or directories with two sets of "..." or "()" wont transfer as those characters are perfectly valid in Windows, you can use them all day long as many times as you want. Better error handling would be good. The behavior when an invalid character is found should not be to continually attempt to transfer the files forever with out giving an error to the user. Skipping the file and logging the error and reporting it would be more optimal.

What characters were in the file name. I have seen the same issue between Linux and Windows. I have seen that a portion of my music library (~150GB, 25,000+ files) that have certain characters will get stuck and transfer forever. Files or directories with any of the follow may get stuck: One or more "?", or two sets of "()" or two sets of "...", some examples: Megadeth - Peace sells... but whose buying? - Peace Sell... but whose buying?.mp3 Bob Dylan's Greatest Hits (Bootlegged) - Like A Rolling Stone (live).mp3 Question marks are not valid in Windows, which is really unfortunate. I can't comment on why the "..." and "()" cause a problem... only when used twice in the same file or dir name, though... One thing is for sure, Sync needs to handle the error better. It should skip the files, and log the issue, and move on, and let you know later what it didn't sync and why. Instead it appears to waste bandwidth by continually trying to transfer the files. That is very bad behavior. I really wish there was formal bug reporting tool for Sync. I'd love to know what issues that have been reported are currently being worked on and which are red herrings or related to other known problems!

I am interested, but I think this is a big ask...

Indeed. Commenting out the default Ignore rules doesn't seem to have helped. I think it might be a more fundamental problem with punctuation handling on the receiving end. I have also seen it stall when a track has more than one set of ()'s or more than one set of ellipses - I wrote it of as random, as it doesn't seem to happen as often, but I also sure there are far far fewer instances of files that fit that pattern. Currently I have 3 songs stalling, two with ?'s and one with two sets of ()'s. This happened after transferring several dozen files with out a problem. I have not had it stall on anything that did not have fishy punctuation in the titles. But as these are song titles, its not unexpected or avoidable. I have transferred about 120 of 150GB successfully, had to edit files half dozen times and restarted a couple times so I have fairly reasonable sample size, over 20,000 files. I have successfully transferred over a hundred gigs of files with out any trouble, except for some of the files and dirs with ?, () and ellipses. Song's with these patterns are a fairly small percentage of the total, so outside of some other pattern I am not seeing it really looks like the right instance of punctuation is trouble some of the time. Note I am not a programmer, but I do write the occasional bash, perl or php script... I am aware that special attention is needed when parsing punctuation... so my thoughts go there, something is reading the names and it hitting the "?" and instead of seeing it as part of the string or name maybe it's being interpreted as code, or as an expression, maybe that's what its mentioning syntax...... but again, not a programmer... just a guess.

It appears to be transferring the files over and over, or more accurately, continuously, never finishing. This bug is pretty serious as if left alone will needlessly eat up bandwidth between the peers forever until the user notices. If you are doing a big transfer it could be days until you bother to look closely enough.

Does Sync create .SyncIgnore automatically, I do not see them? Should they exist in the root folder on both peers?

I have not edited the .SyncIgnore file, so it is default. If the "137 error: <NULL> meta: 1" is not an error message then I do not see any indication in the sender side log indicating a problem, so perhaps that points the receiving side being the problem. I should also note that the "137 error" ALWAYS appears in context of the Receiving side error. I have not looked in the .SyncIgnore file. Is there a useful test we could do by removing or editing the .SyncIgnore file in attempt to rule out or prove that it may be acting like a wildcard in some broken way?

Anyone else seeing this error? Peers are Debian 32bit and Windows 7 32 bit, both version 1.0.134 Receiving side error example(Windows 7): Error: 65daysofstatic-The Fall of Math-11-Aren't We All Running?.m4a - WriteToDisk: The filename, directory name, or volume label syntax is incorrect. Sending side error example (Debian 6): [20130431 10:02:25] Torrent 65daysofstatic-The Fall of Math-11-Aren't We All Running?.m4a status: 137 error: <NULL> meta: 1 Other examples include "Alice In Chains - Dirt - Would?.m4a", etc, etc... Seems to only happen on directories or files with a "?" question mark in the name. BUT not all files or folder with question marks, some work fine. For example. Mega Death - Peace Sells... but who is buying?... stalled, would not transfer. But several others with "?" in the title seemingly worked fine, like "O Brother Where Art Thou?-..." did not fail. Renaming the folder and/or file, removing the "?" will cause the file to transfer as normal. Otherwise sync continually tries to transfer the file and gives no error, essentially stalling the sync until I intervened. Anyone else see this pattern? I wondering if the "?" issues is just a coincidence. Is there a formal bug tracker for Sync? Should be one... IMO. -xminer