Red Hat Bugzilla – Bug 962015
Last modified: 2014-01-07 09:35:55 EST
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
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
[harry@srv-rhsoft:~/Desktop]$ stat 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
I can reproduce it, thank you for the bugreport.
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
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
> 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 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.
curlftpfs-0.9.2-14.fc18 has been submitted as an update for Fedora 18.
curlftpfs-0.9.2-14.fc17 has been submitted as an update for Fedora 17.
curlftpfs-0.9.2-14.el6 has been submitted as an update for Fedora EPEL 6.
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.