Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=85692) [details]
obexftp-cablewriteretry.patch

This will apply cleanly to 0.18 as well as 0.19

Created an attachment (id=85693) [details]
obexftp-0.18.ebuild

Created an attachment (id=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 an attachment (id=85776) [details]
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!