curlftpfs-0.9.2-11.fc18.x86_64 basicly transfer of files works, but at the end there is ALWAYS a IO-error resulting in all sorts of warnings from applications, specially eclipse is unuseable write to a ftp-mount by messages that the file on the remote machine may have chnaged and if Eclipse should replace the editors contents as said: the files are compleltly written everytime
What kind of errors you are seen? Does it happened only with eclipse? How reproduce?
as said it happens permanently and is reproduceable with any FTP-server on the other side as well as 2 seconds for a 5-byte-file is a bad joke and you can see the cat from the curlftpfs mount that the file WAS transferred /etc/fstab: curlftpfs#user:pwd@host/httpdocs /mnt/aume fuse noauto,user,rw,noexec,nosuid,nodev,uid=harry,gid=verwaltung ___________________________ [harry@srv-rhsoft:~/Desktop]$ date; cp test.txt /mnt/aume/; date Sat May 11 14:16:29 CEST 2013 /usr/bin/cp: closing '/mnt/aume/test.txt': Input/output error Sat May 11 14:16:31 CEST 2013 [harry@srv-rhsoft:~/Desktop]$ cat /mnt/aume/test.txt Test [harry@srv-rhsoft:~/Desktop]$ stat test.txt File: 'test.txt' Size: 5 Blocks: 8 IO Block: 4096 regular file Device: 902h/2306d Inode: 110101477 Links: 1 Access: (0640/-rw-r-----) Uid: ( 500/ harry) Gid: ( 501/verwaltung) Access: 2013-05-11 14:15:49.703382283 +0200 Modify: 2013-05-11 14:15:49.703382283 +0200 Change: 2013-05-11 14:15:49.703382283 +0200 Birth: -
I can reproduce it, thank you for the bugreport. Seams https://code.google.com/p/curlftpfs/issues/detail?id=6 Could you check if second copy attempt works without error?
> More interesting, a first cp operation fails but creates an empty file. > A second cp operation on the same file works!! is a total different behavior as i explained it does not fail, the files are completly tranferred at the first try maybe something internally doe sthe re-try which would explain the 3 seconds for a 5 byte file
Please provide log with "-d -o debug,ftpfs_debug=5" options of curlftpfs (beware: it may contain your password - cut off it).
Please try this scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5369151
[harry@srv-rhsoft:~]$ rpm -qa | grep ftpfs curlftpfs-0.9.2-13.fc20.x86_64 has the same problem, did it change the behavior for you? BTW this bugreport is for F18 and *not* Rawhide! > Please provide log with "-d -o debug,ftpfs_debug=5" options of curlftpfs please explain how to use this in /etc/fstab
(In reply to comment #7) > [harry@srv-rhsoft:~]$ rpm -qa | grep ftpfs > curlftpfs-0.9.2-13.fc20.x86_64 > > has the same problem, did it change the behavior for you? Yes off course. But according to your coment 4 we have different issues. I can't reproduce yours now. > BTW this bugreport is for F18 and *not* Rawhide! Off course. When we fix ussue and you provide feedback after testing it worked I'll push updates. > > > Please provide log with "-d -o debug,ftpfs_debug=5" options of curlftpfs > please explain how to use this in /etc/fstab Better way to do that just run it in console like: curlftpfs -d -o debug,ftpfs_debug=5 user:pwd@host/httpdocs /mnt/aume then on other console try copy new file: [harry@srv-rhsoft:~/Desktop]$ time cp test.txt /mnt/aume/ Copy log and past it there.
Created attachment 746881 [details] debuglog debuglog with user/pwd/host masked the only action was * curlftpfs -d -o debug,ftpfs_debug=5 ***@**/httpdocs /mnt/aume * cp test2.txt /mnt/aume/ this is a textfile created by echo "TEST" > test2.txt so nothing special
Hm, very interesting. Could you please test that build - http://koji.fedoraproject.org/koji/taskinfo?taskID=5369304 ? And please, mount empty directory, not root, or better directory with 1-2 files. Something similar to: curlftpfs -d -o debug,ftpfs_debug=5 ***@**/httpdocs/temp /mnt/aume
Created attachment 746893 [details] debug-log with curlftpfs-0.9.2-13.1.fc20.x86_64 curlftpfs-0.9.2-13.1.fc20.x86_64 works without IO-errors even on the docroot however, attached a debug-log as suggested mounted a test-folder with 2 files please give us a F17/F18 build, AFAIK this problem exists since years and god bless that i mostly use sshfs and no ftp-servers :-)
Ok, thank you very much for report and testings. Updates follow. But why you do not favor sshfs?
> But why you do not favor sshfs? i *do favor* as said but there are sometimes servers of customers which i do not control and offer only FTP (in summary 3 out of 700)
Indeed. Sorry for misunderstood.
curlftpfs-0.9.2-14.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/curlftpfs-0.9.2-14.fc19
curlftpfs-0.9.2-14.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/curlftpfs-0.9.2-14.fc18
curlftpfs-0.9.2-14.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/curlftpfs-0.9.2-14.fc17
curlftpfs-0.9.2-14.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/curlftpfs-0.9.2-14.el6
curlftpfs-0.9.2-14.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
curlftpfs-0.9.2-14.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
curlftpfs-0.9.2-14.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
curlftpfs-0.9.2-14.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.