Version: 3.1.94 (using KDE 3.1.94 (CVS >= 20031206), compiled sources) Compiler: gcc version 3.3.2 (Debian) OS: Linux (i686) release 2.6.0dell-optiplex MiddleMouseButton-click on a file which exists on a remote machine (via (ssh) fish) will open it in (for example) kwrite. The normally goes well; unless the remote file is smaller then some 1000 bytes, then the protocol freezes and I have to press the cancel button on the progress dialog for it to show (yes it actually shows the file after a cancel). I could only reproduce this by MMB clicking on a file in konqueror; some investigation shows that the server on the remove end is started 3 times in less then 5 seconds, so my guess is some race condition...
Hallo Jörg, if you are maintaining fish please be also aware that it is not LFS clean. Instead of using "int" please use "KIO::filesizt_t" and "KIO::fileoffset_t" unfortunately fish also uses values of -1 as flags, better define something like "FISH::nowhere" as "(unsingned long long)(-1)". Please consider the following trivial patch to make fish display the size of long files correctly: diff fish.cpp fish.cpp.old 894c894 < atom.m_long = line.mid(1).toLongLong(&isOk); --- > atom.m_long = line.mid(1).toInt(&isOk); The little patch does not correct most of the LFS issues, but is better than nothing. I also had a lock at the other problems, but if I would fix them that would result in a partial rewrite of fish. Yours Jürgen
As for me, the problem occurs as soon as I wish to transfer a file <1k from the remote location and, unlike Mr. Zander, pressing the cancel button won't make it appear on my side (actually, a .part is created during the transfer but it is erased after I press cancel). I have KDE 3.2.3 on Mandrake Cooker. I found a thread on this for SuSE: http://lists.suse.com/archive/suse-linux-e/2004-Jul/3311.html And here is a screenshot I took of a stalled dialog box: http://vid.ericmartel.net/fish_stalled.png
I don't have much more to add than that I have the same problem. A file with 1024 bytes hang but with 1025 bytes it opens normally. I'm running a week old compile of the sources from CVS. /Ulf
*** Bug 88042 has been marked as a duplicate of this bug. ***
Similar to Bug 87109? http://bugs.kde.org/show_bug.cgi?id=87109 (Which seems to be already fixed) I have the same problems here with a SuSE 9.1 installation using the actual SuSE KDE 3.3.0 supplement binaries. Copying files <=1024 bytes (drag&drop from a fish: to a local konqueror directory) hangs after the data is transferred, waiting for more data... With sftp: and smb: this problem doesn't seem to occur.
Same problem here: current debian unstable, Kernel 2.6.8, KDE 3.3 (I really love fish:// and use it quite often for transfers)
*** This bug has been marked as a duplicate of 87109 ***
I have the same problem. This is then a fish problem? Ok, I just resolved it partially modifying the value "1024" of the mimeBuffer to "1" (Now I cannot copy files smallers than 1 byte, Who have files smallers than 1 byte?? :P). It is changing the all "1024" values for "1". But that solution is not optimized, of course. I think that fish must be optimized. Some comments in there and some things not already finished. Byes.
In today's CVS (16 11. 04) the bug still appears. So perhaps it should not be closed...
This bug still (partly) exists in current CVS. Reopening. I noticed the problem with several different files; but I also noticed at least one file that was 705b and opened correctly. I'll attach one file that had this problem.
Created attachment 8363 [details] failing file. Note that I cleaned out the content of this file for privacy purposes but making it smaller had no change in fish's incapability to handle the file. Growing the file to larger then 1Kb was the only way to get it copied correctly.
For large files (>2GB) see bug #79573
See also bug #89296 (probably a duplicate)
*** Bug 89296 has been marked as a duplicate of this bug. ***
*** Bug 94946 has been marked as a duplicate of this bug. ***
I think this is the same as #124938 as I can no longer reproduce it with the fix I made today. *** This bug has been marked as a duplicate of 124938 ***