I had trouble sending files to my phone where it would hang at the 'Sending "<file>".../' line, so I tracked down the issue and wrote a patch for it. It looks like one could consider this a workaround for fixing the relevant driver itself ( I haven't bothered to figure this out), but my patch just adds a retry loop to the function that writes data to the cable driver, which was failing because the write() call was only writing part of what was requested. Should be completely safe from infinite looping, but if I'm wrong (say write perpetually returns 0, if that's even possible), the results are not catastrophic by any means, because there's a usleep(1) call in the loop as part of the workaround. So in short, applying this patch can only be good, and may perhaps fix issues with more than just my specific model of phone.
Created attachment 85692 [details, diff] obexftp-cablewriteretry.patch This will apply cleanly to 0.18 as well as 0.19
Created attachment 85693 [details] obexftp-0.18.ebuild
Created attachment 85695 [details] obexftp-0.19.ebuild
100 tries seems a bit much and also you didn't took into account the fact that write() could always return 0 (which IMO is an error by itself). I will change the patch in such way to abort after 3 _consecutive_ errors. That sounds OK?
(In reply to comment #4) > 100 tries seems a bit much and also you didn't took into account the fact that > write() could always return 0 (which IMO is an error by itself). > I will change the patch in such way to abort after 3 _consecutive_ errors. That > sounds OK? > The reason I set it to 100 was to make sure that transfers don't fail because of "Resource temporarily unavailable" errors, which is quite possible if the fail threshold is less than 5 errors. Making it consecutive would alleviate that issue, but I don't think making the number high is a problem, cause worst case, the loop would run for less than 5 secs if it encountered 100 write() errors (based on my highly unscientific observations), and this is an unlikely circumstance. I tried to unplug my phone during a transfer a few times to trigger it, and it didn't happen, the connection was terminated and obexftp promptly closed. Also, failing this, there still is the option for the user to send an interrupt to the program, which would terminate it immediately. Even if you make it keep track of consecutive errors, which is a good thing, my opinion is that the fail threshold should be set significantly higher than 3.
Created attachment 85776 [details, diff] obexftp-0.19-cobex_write.patch Please try this patch.
well, does it work for you?
Hey, sorry about the delay, I've been busy in the past few days, moving to school, etc., and haven't checked my email. I'll try to remember to try it tonight.
Seems to work, which I would expect, given its similarity to the original working patch. I've tested a 9kB HTML file as well as a 3888kB file.
fixed in 0.19-r1. thanks!
