Created attachment 474512 [details] Patch for fixing bug Description of problem: If I'm mounting remote ftp with curleftpfs 0.9.2 as folder on my local computer (x86_64) and copy any file to the ftp I have Input/Output error. But copied file is not corrupted. Version-Release number of selected component (if applicable): Fedora 14 x86_64 with gnome (all linux with curlftpfs 0.9.2 and x86_64) Steps to Reproduce: 1.yum install curlftpfs on 2.mounting ftp to local folder using following command: curlftpfs ftp://<login>:<password>@<ftp address> /home/<user folder>/ftp 3.copy any file to ftp (use command promt or nautilus or other file manager) 4.getting error ;) Additional info: For fixing error I suggest patch (in attach).
https://sourceforge.net/tracker/?func=detail&aid=3163514&group_id=976&atid=100976
Hi, this problem isn't libcurl. This internal problem curlftpfs 0.9.2. Patch fixing curlftpfs 0.9.2
Yes, off course it was my mistake. https://sourceforge.net/tracker/?func=detail&aid=3163909&group_id=160565&atid=816357
Thank you for the bugreport and help. Fix in rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=3157786
Can we get a build for Fedora 14 and 15? Having a fedora 14 bug fixed in rawhide is not much of a resolution, as I can't upgrade a system I use everyday for work to rawhide.
Ironically, the whole reason I'm even trying to get curlftpfs working is so I can share rpm's I've built to fix other bugs on my website.
BTW. I compiled the source rpm, and it works fine for Fedora 15. I went to see if I could queue this up on koji.fedoraproject.org myself, but it looks like there login function is broken: Secure Connection Failed An error occurred during a connection to s390.koji.fedoraproject.org. SSL peer was unable to negotiate an acceptable set of security parameters. (Error code: ssl_error_handshake_failure_alert) If you can point me in the right direction as to how, I will try to queue up a build Fedora 14 and 15 myself.
Created attachment 529536 [details] curlftpfs src.rpm Hi Error code: ssl_error_handshake_failure_alert isn't bug of curlftpfs. In attach I include my src.rpm. I hope this help you. For rebuild this package for Fedora 14/15 see http://fedoraproject.org/wiki/Building_a_custom_kernel
Hi Victor, you are right it isn't. I already built a the rpms from your source. In fact I've even uploaded my builds to a private yum repo to share with my friends. I am thinking more about all the other fedora users. The whole point of having updates, is so fixes like this can be pulled by yum, not rebuilt by every single user. I was posting the error, in hopes you could explain to me how you work past this error to submit a build task on koji.fedoraproject.org so we can get something in the Fedora updates to fix this problem. Bill
BTW. The simple way for end users to rebuild packages is: mock --rebuild curlftpfs-0.9.2-8.fc16.src.rpm Provided all the dependencies are set correctly in the package it pulls down all the resources needed and builds the package. You can even use it build for other targets: mock -r fedora-14-i386 curlftpfs-0.9.2-8.fc16.src.rpm Of course this method just plain sucks if you have a slow network connection or limited bandwidth, as you end-up pulling down huge parts of the distribution you are building for to resolve all the dependencies. Here is a link to a fedora 15 x86_64 build. http://www.foxtrottechnologies.com/fedora/releases/15/Everything/x86_64/os/Packages/curlftpfs-0.9.2-8.fc15.x86_64.rpm
Ahhh. I found the koji instructions and submitted the packages to build. I have not determined yet though, once the packages are built how do they get added to the fedora updates?
curlftpfs-0.9.2-8.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/curlftpfs-0.9.2-8.fc14
curlftpfs-0.9.2-8.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/curlftpfs-0.9.2-8.fc15
Ok, updates pulled, test it - https://admin.fedoraproject.org/updates/curlftpfs-0.9.2-8.fc14 , https://admin.fedoraproject.org/updates/curlftpfs-0.9.2-8.fc15
Package curlftpfs-0.9.2-8.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing curlftpfs-0.9.2-8.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-14807 then log in and leave karma (feedback).
Still not working on Fedora 15 with SSL. Oddly, mounting with -d option make everything work ...
Ok, the patch is wrong (CURLOPT_INFILESIZE should not have been defined in any case and correct usage is : it should be a long if used with curl_off_t typedef, so just remove it alltogether, it's unused anyway in the source) . Please use patches from http://anonscm.debian.org/viewvc/collab-maint/deb-maint/curlftpfs/trunk/debian/patches/ to fix the issue (and more issues). Thks.
It definitely fixed the issue with non-ssl connections. Maybe this bug should be split, as there seems to be at least two distinctly separate problems, only one of which has been address by this patch.
Created attachment 530287 [details] Real fixes for SSL or non SSL connection or memleaks Fully tested.
SSL or TLS connection are still fuzzy with either patches kit. After the clone(2), the process hang randomly ... I can't investigate further right now.
I agree, please open new bug for onother problem! Initially reported problem fixed as I can understand.
It's fixed not correctly as I've already explained, CURLOPT_INFILESIZE is not used as intended by libcurl. Anyway, it's an upstream work to fix it properly but the two other patch that fix memleaks are correct and should be included ASAP.
Created attachment 531666 [details] Better fixes for this bug and memleaks TLS or SSL connection are still not thread safe (well, in theory yes but for an still unknown reason, it's not, not sure the SSL and thread safety pb belong to this package). By the way, the curlftpfs git repo on the Fedora package DB is a *real* mess. The maintainer should really clean it.
Created attachment 531668 [details] The right patch, at least. The mess has kill me ...
Jérôme, it ticked was not about memory leak! And yes, please stop do sucm mess there!
You have definitively not read the patch. It do fix the bug reported here *correctly* + properly change the changelog entry + plug two memory leaks as a bonus. If the maintainer don't care to fix the reported bug correctly, the changelog entries and as a bonus memleaks, I don't care either :) SSL or TLS FTP still have issue, thread safety one. I will open a bug report for SSL and TLS if you want but I will not open a new bug report for each memleaks, it's just plain silly and a waste of time, each patch are related to effective bug # reported on Debian bug tracking system, correct and tested since years on Debian like distro. I've done all the work, just enjoy it and integrate the work on Fedora as soon as you can. Cheers.
The reason it makes sense to do separate bugs for separate issues, is it is a separate verification. Since the first build solved the initially reported problem and was verified, it makes sense to push that to testing and then updates without delay waiting to verify the fixes for other problems such as memory leaks. Each fix, also has the potential of breaking something else, so the other advantage of separating them in separate bugs is that it is easier to way the pros and cons. e.g. Is fix foo significant enough to push to Fedora 14 and Fedora 15? Or are the risks such that it should be deferred to Fedora 16 beta, or maybe even left for Fedora 17's rawhide. Or maybe it is such a low priority it is just better to wait for the fix to be pushed upstream. Now this is not nearly as much work as it sounds. If you feel that bugs are related, then using the clone bug button to pull in the discussion history on the new bug makes sense. If several memory leak fixes should all be tested together, you can mark one as a dependency of the other...
Ok. I can make separate patch et fill a bug report report for each patch, as soon as I can.
Ironically this patch solved the problem for Fedora 14 and Fedora 15, but not for Fedora 16 where the fix was first pushed. I opened a separate bug tracking this problem in Fedora 16. Bug 753020
It looks like Bug 753020 is a completely different issue.
Created attachment 534307 [details] Correct fix For only this bug number. I've not incremented Release 'cause I hope you've not shipped the previous wrong fix. Cheers.
Please, contact with upstream author for discuss about possible solutions.
Pavel, upstream is unresponsive since years. I very well understand that package maintainers do not have to take over and fork upstream development but when upstream is dead and when a gentle contributor provide *correct* patches, package maintainer should not really close bugs and don't integrate correct fixes. All the bugs and patches I've respectively reported and sometime fixed myself correctly are already in the upstream bugs tracker and upstream is unresponsive (which mean you've opened duplicate bug report in upstream bugs tracker, not a big deal). So, pretty please, do not force me to reopen each bug reports I've done, I'm unfortunately somewhat busy and not very inclined to fight with a package maintainer to make Fedora a better distro, just integrate my patches first in rawhide for testing purpose, then give them a updates-testing test coverage, then ship the package in updates for each stable version, it's just common sense. If one day upstream wake up and fixes all bugs reported in their bugs tracker with a brand new version, you will then drop each patches in the .spec and sources files, it's that simple. This comment also apply to bz#754823 and bz#754824 that I will not reopen unless you force me to do so. I will probably one day work when time permit on the thread safety issue with curlftpfs and the FUSE quota API change 'cause I'm using curlftpfs and Fedora very often and propose my fixes upstream and here and I do not expect that you will not integrate my fixes in Fedora when upstream is unresponsive since years. Ok ?
Jérôme problem with it what I though I have not experience to audit that patches. Why you do not want became author of curlftpfs if you interesting in it? O fork it?
Pavel, Could you sponsor me as a co-maintainer of curlftpfs ?
I'm not sponsor unfortunately. So, I can't sponsor anyone. But If you are existing Fedora maintainer I'd be happy grant you co-maintainership on curlftpfs. You did not answer why you do not want became upstream co-author?
No, I'm not a Fedora package maintainer, I will ask for sponsorship. Co-maintain one or two package in Fedora is ok with my schedule, co-maintain one more FOSS code base will not fit in my schedule, I really can't add more. Cheers.
Please, can you provide clear patch instead of patch on patch? I'll look on it and integrate in package.
curlftpfs-0.9.2-8.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.