Version: 4.2.69 (using Devel) OS: Linux Installed from: Compiled sources since a few days i'm getting "connection to host xxx.xxx is broken" when trying to copy (small) files from my local machine to a server. konqueror begins to copy the file, but stops after a few bytes with the above error. i'm using KDE 4.3 as my working environment, but keep 3.5.10 updated, just in case. using konqueror 3.5.10, even from within a running 4.3 session, fish works fine. (afterwards the 4.3 version of konqueror won't connect via SSH anymore at all, though.)
trying to find out more about this apparent bug that nobody else seems to experience, i deleted the fishsrv.pl file from my server, and after it was re-created, i un-commented some debug & debug-print statements in it. the resulting kio_debug files showed what's probably normal for operations that didn't fail: ---------------- #VER 0.0.3 copy append lscount lslinks lsmime exec stat #STAT /home/phani #DELE /home/phani/empty_scores_form.doc #DELE /home/phani/kio_fish.debug.9016.log #DELE /home/phani/mayapurLive.jpg #LIST /home/phani ---------------- but every time an operation did fail, like copying a file from local to the server, the kio_debug file was blank. i suspect it has something to do with mime-types, since i could upload *.ico and *.log files, but not images or *.swf. this works when i use ftp instead of fish, or when using the fish protocol in konqueror 3.5.10. next i set up a new user account (local), thinking i might have messed up settings--but the same thing happens: fish doesn't work with konqueror 4.2.69, but does with 3.5.10. i'm puzzled, but not disturbed, since i can always use the 3.5 version...
now i find that kate (4.3) also doesn't work with fish protocol anymore, giving the same error message, that "the connection ... is broken." this means it's not an issue with konqueror, but with my whole KDE 4.3 installation. sorry for bothering you, i'll go and look what i find in KDE forums & bugs...
*** Bug 192619 has been marked as a duplicate of this bug. ***
*** Bug 193270 has been marked as a duplicate of this bug. ***
*** Bug 193492 has been marked as a duplicate of this bug. ***
*** Bug 193696 has been marked as a duplicate of this bug. ***
Just to confirm that this bug is also present at my installation. The "connection to host ... is broken" appears in Konqueror, Krusader, Dolphin and all KDE 4 dialogs. The KDE version is 4.2.85-52.1, the distribution is openSuse 11.0.
I cvan confirm this bug too. Opensuse 11.1, KDE 4.2.88 (and earlier).
I can confirm this with openSUSE 11.1 and KDE 4.2.88
*** Bug 195367 has been marked as a duplicate of this bug. ***
*** Bug 195973 has been marked as a duplicate of this bug. ***
Seems to depend somehow on Nepomuk, which is disabled on my machine. Reenabling and afterwards disabling Nepomuk again fixed this issue temorarily for me.
(In reply to comment #12) > Seems to depend somehow on Nepomuk, which is disabled on my machine. Reenabling > and afterwards disabling Nepomuk again fixed this issue temorarily for me. good for you; in my case this doesn't help, though...still getting the broken connection, with or without nepomuk enabled. phani.
oops, i'm sorry; i didn't listen properly. when i did what you wrote, disable nepomuk, then re-enable it, fish started working again in KDE 4.3 dialogs! so it looks like it is connected to nepomuk, after all. phani.
I resolved MY issue. Let me explain. Normally I would just type fish://...etc... in the address bar and it works, then make a placeholder in 'Places' I had an existing Bookmark/Placeholder in Places to fish my server Once I upgraded to 4.3Beta It reports broken But if I open Konq kde3 - It works. I decided to go 'Network' in Dolphin's 'Places' - Add New Network Folder' Gave the same details as my current server place. It creates a new folder in 'Network' It works So does the old places for the server. All good now! Strange..
*** Bug 183384 has been marked as a duplicate of this bug. ***
*** Bug 196169 has been marked as a duplicate of this bug. ***
Thorsten, can you give a look at this issue? Thanks
*** Bug 196936 has been marked as a duplicate of this bug. ***
(In reply to comment #18) > Thorsten, can you give a look at this issue? Thanks No problem - as I describe at http://www.staerk.de/thorsten/index.php/147948 I have fixed a small-copy-via-fish issue for KDE 4.2. I cannot reproduce a problem with KDE 4.3. Everyone who sees a problem - can you please run my testcase from http://websvn.kde.org/trunk/KDE/kdebase/runtime/kioslave/fish/tests/ and tell me about the result?
How am I supposed to run it? I downloaded the files, ran "cmake ." in the dir and not much happened. I also tried "g++ -o copytester copytester.cpp" but there was lots of exceptions. Can you give instructions on how to compile it, precompile it or make test easier accessible in other ways?
Here are the instructions: http://www.staerk.de/thorsten/index.php/147948#procedure for compile: cmake . && make
Here is the complete readme: http://websvn.kde.org/trunk/KDE/kdebase/runtime/kioslave/fish/tests/README?view=markup
Also, please start konqueror in a konsole and copy the console output here. The relevant part should read like select failed, rc: 5, error: ... and should also reveal which function the error occurs in. However, as I see from the code I guess rather that the perl process (fishsrv.pl) dies - can you confirm? Not so easy, I know...
I compiled and ran your testcase. The program ran in an endless loop without copying ANY file, prompting for my local username and password again and again. Both konqueror and dolphin throw the same errormessage on bash (dolphin on startup, konqueror when accessing localhost via the fish KIO slave): --- "/usr/bin/konqueror(14929)" Error in thread 3049723648 : "org.freedesktop.DBus.Error.ServiceUnknown - The name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files" "/usr/bin/konqueror(14929)" Error in thread 3049723648 : "QLocalSocket::connectToServer: Invalid name" ---
*** This bug has been confirmed by popular vote. ***
Please be of great help and attach the output of konqueror when it dies. It should contain a line like select failed, rc: 5, error: ...
On Tuesday 23 June 2009 08:13:26 am tstaerk wrote: > https://bugs.kde.org/show_bug.cgi?id=189235 > > > > > > --- Comment #27 from tstaerk <dev staerk de> 2009-06-23 15:13:23 --- > Please be of great help and attach the output of konqueror when it dies. It > should contain a line like > select failed, rc: 5, error: ... > > OK, I'll give it a shot and post the output. Like I mentioned earlier, after trying between 3-25 time it will finally connect (If you have the luxury of the refresh button like in konqueror). But if the app you are using just makes use of the fish_kio, you are dead in the water. Also, I have noticed that after updates, fish is broken again for each site and you have to go through the 3-25 times of refreshing before connecting again. We shall find the culprit.
Not all good now and the fish kio still will not connect on konqueror until you try any where from 3-25 times. When you first try on 4.3beta2 openSuSE, you get the error: The requested operation could not be completed Connection to Server Closed Unexpectedly Details of the Request: URL: fish://ecstasy Protocol: fish Date and Time: Thursday 25 June 2009 03:04 am Additional Information: ecstasy Description: Although a connection was established to ecstasy, the connection was closed at an unexpected point in the communication. Possible Causes: There may have been a problem with your network connection. There may have been a problem at some point along the network path between the server and this computer. A protocol error may have occurred, causing the server to close the connection as a response to the error. Possible Solutions: Try again, either now or at a later time. Contact the administrator of the server for further assistance. Contact your appropriate computer support system, whether the system administrator, or technical support group for further assistance. (I ran konqueror from konsole with /usr/bin/konqueror to see if I could catch any console messages - none were shown.) No syslog messages either. If I keep hitting the reload page. So hitting 'reload' 1,2,3...11 times was the magic number and the listing of my files finally are shown instead of the above error. Tell me what error/log/etc you want me to get and I'll provide it. I would really like to see this one squashed. I can hit refresh 20 times, but all apps that use fish just bomb when the first connection dies....
For the 3rd time: Please be of great help and attach the output of konqueror to the console when it dies. It should contain a line like select failed, rc: 5, error: ... I have verified that you receive fish messages in konqi's output as long as you have build kio_fish for debugging. Here is a tutorial: http://techbase.kde.org/Getting_Started/Build/KDE4
Konqueror is silent. There is no output when the connection dies and no output when konqueror is closed. I'm using prepackaged ubuntu packages and I have the dbg packages installed.
When it works (it does sometimes), I get this message: "/usr/bin/konqueror(9614)" Error in thread 140376384866144 : "org.freedesktop.DBus.Error.ServiceUnknown - The name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files" "/usr/bin/konqueror(9614)" Error in thread 140376384866144 : "QLocalSocket::connectToServer: Invalid name"
(In reply to comment #31) > Konqueror is silent. There is no output when the connection dies and no output > when konqueror is closed. > > I'm using prepackaged ubuntu packages and I have the dbg packages installed. Then file a bug at Ubuntu or compile it from source. Please understand me: I cannot reproduce the problem. I depend on you to give me input. I can install Ubuntu easily on a virtual machine, but, in the end, it's you who wants the problem to be solved.
I understand that it's frustrating. I give as much information as possible for me right now. I suppose it's better than no information. There are many of these duplicates that have built from source, I don't know why they don't answer.
I only want to confirm Pascals observation. I have openSUSE packages installed (with all relevant debuginfo packages as far as I can tell). But the only output I get is when the connection works sometimes: "/usr/bin/konqueror(31202)" Error in thread 3051329280 : "org.freedesktop.DBus.Error.ServiceUnknown - The name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files" "/usr/bin/konqueror(31202)" Error in thread 3051329280 : "QLocalSocket::connectToServer: Invalid name" However, if I then try to copy a local file the the remote computer I get a message telling me the connection is interrupted, but still no output on konsole.
*** Bug 198641 has been marked as a duplicate of this bug. ***
*** Bug 198937 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > Just to confirm that this bug is also present at my installation. The > "connection to host ... is broken" appears in Konqueror, Krusader, Dolphin and > all KDE 4 dialogs. The KDE version is 4.2.85-52.1, the distribution is openSuse > 11.0. Same here on OpenSUSE 11.1, KDE 4.2.95
Same here on Kubuntu 9.04, KDE 4.2.95
Same here OpenSUSE 11.1, KDE 4.2.95 and OpenSUSE 11.0, KDE 4.2.95
Can anybody please increase the priority and severity for this bug?
Everyone, please vote for this bug, I beg you!
for i in $(seq 1 1 100); do touch /tmp/fishtest${i}.txt; done cmake . && make -j4 && rm /tmp/test/*; ./copytester I get a popup with "Connection to host localhost is broken" and if I select Auto-skip I get in my konsole: A KUiServerJobTracker instance contains 1 stalled jobs
> Everyone, please vote for this bug, I beg you! Why? What good does that do? https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&votes=21&order=bugs.votes
It does good that the bug gets attention. It does no good as long as there is no way for us to reproduce the bug. I still cannot reproduce the bug, fish:// and the testcase run smoothly for me.
*** Bug 199458 has been marked as a duplicate of this bug. ***
For Completeness, here is the information for Bug 199458 that has been marked as a duplicate of this bug. If I don't need to repost, let me know that the fact that it was marked a duplicate is sufficient to insure that the information I submitted under the duplicate will be considered here and I will refrain from reposting in the future. The problems I had with the copyto -> browse -> fish://mysite.com are: konqueror's "copy to" feature using the fish protocol is broken. When selecting the "copy to" -> "browse" feature, you are unable to enter and browse to a remote connection using fish like you can in KDE3. Entering the fish:// URL directly in the address box there is no folder completion. If you hit enter, then a "zero" byte file with the correct filename is copied to the remote host. The KDE4 notification window show that a successful copy was completed when in fact a zero byte file was all that was copied. See: http://www.3111skyline.com/download/openSUSE_bugs/kde4/screenshots/fishCopyKonquerorBroken2.jpeg using gtfp with fish/ssh works just fine on the same file. This is a huge problem for remote management of files and a huge bug in kde4 konqueror. One of the most frustrating parts of this bug is the fact that you cannot even copyto -> browse fish connections even though you can type the fish address in the main konqueror address bar and go right to the fish location (Yes I had to hit refresh 5-6 times before the initial fish connection was made, but then it connects fine) The copyto -> browse was attempted after the fish connection was established with the main address bar. The copyto -> browse address window (at the bottom of the copyto -> browse dialog) is completely unresponsive. What the heck happened to copyto via fish in kde4 konqueror? opening /opt/kde3/bin/konqueror (KDE3 konqueror), and choosing copyto -> browse and then typing fish://mysite.com and pressing enter immediately brings up the folder listing for the remote site and you can then just click on the folders to choose the folder to copyto. It works flawlessly. Seriously consider restoring the konqueror backend to konqueror in KDE4. It is very apparent that the current dolphin backend for konqueror in KDE4 simply "does not work" and "does not provide needed basic functionality" that konqueror has always had. If you simply provide KDE3 functionality for konqueror in KDE4, I would be more than happy. Even providing the user the ability to choose which backend to use for konqueror (konqueror or dolphin) would fix many of the konqueror bugs in KDE4. I would like to delete my KDE3 install, but I simply can't due to bugs like this where I cannot do what I need to do in KDE4. Let me know if I can provide more info on this one. I would like to see this one fixed. It is one of the biggest (fish bugs in general) that prevent me from being able to use kde4.
(In reply to comment #48) I forgot to mention, this is with kde 4.2.95 from openSuSE
@david rankin: "Seriously consider restoring the konqueror backend to konqueror in KDE4" well, that functionality is sttill available--in konqueror 3. just use that for fish operations, that's what i do. for some reason this bug doesn't happen to everyone, most notably the developers don't seem to be able to reproduce it. what to do? konq.4 does have a lot of new features that do work. phani.
Unsubscribing because no way to reproduce. I am not the author of kio_fish.
(In reply to comment #50) > @david rankin: > > "Seriously consider restoring the konqueror backend to konqueror in KDE4" > > well, that functionality is sttill available--in konqueror 3. just use that for > fish operations, that's what i do. for some reason this bug doesn't happen to > everyone, most notably the developers don't seem to be able to reproduce it. > what to do? konq.4 does have a lot of new features that do work. > > phani. That's the issue isn't it?? KDE3 has been cast off like a worn out shoe, but you still can't do the things you need to do in KDE4 that can be easily done is KDE3. Oh what a tangled web we weave. On the issue of reproducibility. I can reproduce the copyto -> browse bug every time. Just put the focus on a file, rt-click to get the context menu, choose copyto, choose browse, the try and type a fish://domain.tld/ and press return to get a file listing. Result: you get nothing. Not because of the fish issue, but because of the broken dialog not issuing any connect attempt. I had gone through the process of typing fish://domain.tld and then hitting refresh 5 times to get beyond the broken fish issue. After the failed attempts and you successfully make the connection, fish will work for that site every time until the next KDE4 update. I'm talking about the copyto->browse function not even trying to make the fish connection. That's why I don't think the bug I reported is a duplicate of this fish issue, but the devs seem to see "fish" in the bug title and automatically presume the bug is a duplicate of this one -- not the case here. Either way, fish needs to be fixed. The fish issue is reproducable -- always after a KDE4 update. My broken copyto -> browse by is is reproducable every time regardless of whether a fish connection has been previously made to the site in question. Fixing this fish bug will not fix the copyto->browse bug I reported this morning. That is why the bug should not have been marked a duplicate of this bug.
As a workaround, is it possible just to copy the kde3 konqueror to my kde4 installs by copying just /opt/kde3/bin/konqueror? Or, do I also need to copy a number of additional libraries to support kde3 konqueror? I would like to be able to install just the handful of kde3 apps I need in /usr/local or just leave them in /opt/kde3 without having to keep two separate kde installs. Maybe kde4 could include the kde3 versions of konqueror, ksnapshot, etc. as a patch. The kde3 patch could just continue to place a limited number of apps and supporting files in /usr/local or /opt/kde3 until all these issue are fixed. /opt/kde3 seems to make the most sense being that the files already reside there (at least on openSuSE or in /opt/kde on Archlinux) I don't know, I'm just brainstorming how to keep needed functionality while moving to kde4 without having to maintain 2 complete and separate kde installs. Is a workaround like this doable to preserve kde3 konqueror?
(In reply to comment #53) > As a workaround, is it possible just to copy the kde3 konqueror to my kde4 > installs by copying just /opt/kde3/bin/konqueror? Or, do I also need to copy a > number of additional libraries to support kde3 konqueror? if you install KDE 4.3, then add the 3.5 repo and install konqueror 3, it should automatically add any additional libraries, etc. that are required. i think this discussion should go into the forums, though. phani.
You can't use sftp:// as a workaround? btw.. on another computer the test files works. If I enter a fish://user@bla uri in dolphin it doesn't work :( fish://root@localhost works fine.. crazy
Created attachment 35166 [details] output of strace -f starting konqueror from the commandline
(In reply to comment #56) > Created an attachment (id=35166) [details] > output of strace -f starting konqueror from the commandline created this attachment by running konqueror thru' strace -f, starting konqueror with a fish address as command line argument. not surprisingly, the output doesn't tell me much, but i thought somebody else might find useful information in there. konqueror gave the following message: "Although a connection was established to pegasus.ocssolutions.com, the connection was closed at an unexpected point in the communication." phani.
(In reply to comment #55) > You can't use sftp:// as a workaround? for some reason file operations via ftp:// or sftp:// have greater latency, i.e., takes longer to open or copy each file. it's fine to transfer large files, but working with many small ones is painful. phani.
Now I found another crazy thing: fish://root@localhost/home works fine fish://anyotherlocaluser@localhost/home doesn't work
I can add the following information to this bug: 1. Me too... 2. When trying to fish as root (as per comment #59), I am prompted with 2(!) login dialogs, after which I get the 'connection to host ... is broken' (status) message. KDE version 4.2.95
Guys, This has got to get fixed. Broken fish (or whatever keeps it from connecting the first time) kills the ability to work remotely in kde4. Here are some additional pieces of data for the puzzle. Today using kde3 konqueror, connecting to my office via fish worked perfectly: http://www.3111skyline.com/download/openSUSE_bugs/kde4/screenshots/fish-konqueror-kde3.jpeg I then needed to save a text file from kwrite kde4 to the same directory at my office. When I typed the fish url into kde4 kwrite, I immediately got "Connection to host rbpllc.com is broken.": http://www.3111skyline.com/download/openSUSE_bugs/kde4/screenshots/fish-kwrite-kde4.jpeg That's BS, it is running perfectly in kde3 konqueror right behind kde4 kwrite. After pressing OK to close the broken connection dialog. I simply hit F5 five times refreshing the connection in kde4 kwrite and it connected just fine on the 5th try: http://www.3111skyline.com/download/openSUSE_bugs/kde4/screenshots/fish-kwrite-kde4-F5-5-times.jpeg What is the world is going wrong with fish in kde4? Give us some marching orders of tests to try or of tcpdump files to capture so we can narrow down what is broken with fish in kde4. Using kde4 for remote computing is worthless when it takes 15 minutes to sort out why a simple transfer or file save won't work when all it should take is a 1/2 second press of a button. Let us know how we can help. What can we get you? This is not good. I like kde4 but I can't use it if it doesn't work. There is no reason that I should have to keep 2 versions of kde installed just so I can get work done by going back to the kde3 apps to connect remotely using fish. We are almost at the .3 "dot 3" release of kde4 and this stuff is still broken and has been broken since the initial 4.04 release. Let us know what to send and let's get this thing fixed. Thanks.
Created attachment 35227 [details] tcpdump -i eth0 | grep ssh here my tcpdump with a broken fish connect
This may be a fluke, but on my Archlinux install on my laptop with Version 4.2.96 (KDE 4.2.96 (KDE 4.3 RC2)) (4.2.96-1) fish hasn't produced the broken connection for remote internet site. However, for LAN hosts, fish givess the broken connection error. I am attempting to capture a tcp dump and strace to post. I'll post the results separately (if it does it again after I start wireshark and strace -f konqueror)
OK! I have captured the perfect tcpdump file where I attempted to connect by fish to one box on my LAN and the connection failed. I then hit "refresh" 7 times and on the 8th time, fish connected. This should contain all the communications (failures & successes) related to this bug. How can I submit it securely given that it contains the authentication credentials? Who can I send this to in that manner? Also, the strace aborted early in the session with the following error: 14:44 alchemy:~/archlinux/bugs/kde4> strace -f konqueror >strace.konqueror.2 2>&1 *** glibc detected *** strace: munmap_chunk(): invalid pointer: 0x000000000121c610 *** ======= Backtrace: ========= /lib/libc.so.6[0x7f372db9bdd6] strace[0x40840f] strace[0x4058ee] strace[0x404626] /lib/libc.so.6(__libc_start_main+0xfd)[0x7f372db499ed] strace[0x401f69] ======= Memory map: ======== 00400000-00447000 r-xp 00000000 08:06 855718 /usr/bin/strace 00647000-00648000 rw-p 00047000 08:06 855718 /usr/bin/strace 00648000-00656000 rw-p 00000000 00:00 0 0121c000-0123d000 rw-p 00000000 00:00 0 [heap] 7f372d915000-7f372d92b000 r-xp 00000000 08:06 279295 /usr/lib/libgcc_s.so.1 7f372d92b000-7f372db2a000 ---p 00016000 08:06 279295 /usr/lib/libgcc_s.so.1 7f372db2a000-7f372db2b000 rw-p 00015000 08:06 279295 /usr/lib/libgcc_s.so.1 7f372db2b000-7f372dc74000 r-xp 00000000 08:06 387150 /lib/libc-2.10.1.so 7f372dc74000-7f372de74000 ---p 00149000 08:06 387150 /lib/libc-2.10.1.so 7f372de74000-7f372de78000 r--p 00149000 08:06 387150 /lib/libc-2.10.1.so 7f372de78000-7f372de79000 rw-p 0014d000 08:06 387150 /lib/libc-2.10.1.so 7f372de79000-7f372de7e000 rw-p 00000000 00:00 0 7f372de7e000-7f372de9b000 r-xp 00000000 08:06 387149 /lib/ld-2.10.1.so 7f372e063000-7f372e065000 rw-p 00000000 00:00 0 7f372e099000-7f372e09a000 rw-p 00000000 00:00 0 7f372e09a000-7f372e09b000 r--p 0001c000 08:06 387149 /lib/ld-2.10.1.so 7f372e09b000-7f372e09c000 rw-p 0001d000 08:06 387149 /lib/ld-2.10.1.so 7fff31760000-7fff31775000 rw-p 00000000 00:00 0 [stack] 7fff31786000-7fff31787000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted
(In reply to comment #63) > This may be a fluke, but on my Archlinux install on my laptop with Version > 4.2.96 (KDE 4.2.96 (KDE 4.3 RC2)) (4.2.96-1) fish hasn't produced the broken > connection for remote internet site. However, for LAN hosts, fish givess the > broken connection error. for me there has been no change after updating to RC2, still the same broken connection. since apparently none of the developers are able to reproduce this bug, i'm asking myself what's different in their setups from ours? did you ever try this not using trunk? personally i don't have a problem keeping KDE 3.5 around; i sort of like it and sometimes use it just for the heck of it. on my outdated machine it's a bit faster, too. but i don't think it's nice to have this bug around into the 0. release. i already sent backtraces and strace output, as did others, apparently to no avail. i remember one observation that this bug was connected with nepomuk being turned on and off again. did anybody look into this connection yet? phani.
I have a few observations to add, although I realise they're a lot fuzzier than clear tcpdumps or konqueror straces: 1. If I remove ~/.fishsrv.pl, it is only restored until I reach a successful login, all broken connections seem to break before the uploading of the .fishsrv.pl file. 2. If I remove .fishsrv.pl and kill all stale .fishsrv.pl processes on the target machine I allmost had 100% connection success at first attempt. 3. On one machine, removing .fishsrv.pl and killing all stale processes didn't help. I _did_ get immediate connection after scp'ing .fishsrv.pl from one of the other hosts. 4. Once connected, all subsequent actions on the kio-slave are successful (until now). So I think it's safe to say the failure happens before uploading or checking the availability of .fishsrv.pl and there seems to be no causal relationship with existing .fishsrv.pl processes, although it helped getting connected immediately in 2 out of 3 cases, but that might have been sheer luck.
Just to pour some oil on the fire: My problems are gone since (the actions of) my last comment. For the record: I'm currently running 4.2.96 (RC2).
Here is a bit more gas for the fire. After update to 4.2.96, fish is now broken for 'mc'. After easily establishing a connection to a remote host with 'cd /#sh:hostname' attempting to copy a file between the host fails and locks mc up requiring a manual kill of the fish copy session: 4819 pts/0 S+ 0:00 /usr/bin/mc -P /tmp/mc-david/mc.pwd.4187 4846 pts/0 S+ 0:00 ssh -l david nirvana echo FISH:; /bin/sh ( a manual kill is required on PID 4846 to unlock the froze mc session) The strange thing about the fish freeze is that the file being copied is transfered from host to host, the only problem is that when then feeze occurs, it fails to final new line in the file being copied: 15:02 alchemy:~/linux/scripts/install> diff install-flash10.sh rsync/install-flash10.sh 25c25 < exit 0### 200 --- > exit 0 \ No newline at end of file The file ~/linux/scripts/install/install-flash10.sh is the file that was copied when the fish failure occurred and ~/linux/scripts/install/rsync/install-flash10.sh is the file rsynced from the same host in order to produce the diff. fish is still fsck'ed up.
Created attachment 35393 [details] strace -f of fish faillures between machines on LAN OK, Here is the perfect strace to help solve this conundrum. In this case, I opened kwrite "strace -f kwrite". I then tried to open a file via fish on my LAN. Fish, in its crippled state, failed miserably. After 10 refreshes and "broken connection" error, it finally connected. The uploaded file is the strace of that scenario. Hopefully it will provide information to fix this bug. It's damn frustrating when you can't even work on files on your LAN. What are we supposed to go back to with KDE4? ftp'ing the files to the local machine, editing them, and then ftp'ing them back to the original box? Might as well be sneakernet...
(In reply to comment #69) > Here is the perfect strace to help solve this conundrum. In this case, I opened you sure any dev's are still listening? last i heard was one of them signing off, saying he couldn't reproduce the bug, and anyway he wasn't the author of kio_fish. perhaps we're yelling up the wrong tree here? phani.
Created attachment 35396 [details] After successfully opening file in kwrite via fish, connection fails on "save" After getting fish to connect as described in the prior comment, attempting to save the file open over fish fails. This is the first time this has happened. Every time before, once a fish connection was made (even if it took 10 tries to connect), the connection has continued to work. Here, the connection was made, the file was opened, but then fish broke again preventing the file from being saved on the original machine forcing a "Save As" to the local machine to be moved back to the original. Please move this bug up in priority. Again, every time something like this happens, it is a 20 minute - 1 hour loss in productivity required to document the bug, set up a test case and report it. My biggest complaint with KDE4 is you can't "just get work done" without a continually being faced with broken functionality or things that work fine in KDE3. This fish bug is HUGE in that regard. Don't get me wrong, I like kde4. But, as I have said before, it is very frustrating when the simple things, like editing a text file via fish, doesn't work any more. That's why I'm trying to provide all the data I can to get this fixed. Again, if you would like me to run another test case, etc.., just let me know. I'm happy to do it so the problem can be found and this bug fixed. Thanks.
(In reply to comment #70) > (In reply to comment #69) > > Here is the perfect strace to help solve this conundrum. In this case, I opened > > you sure any dev's are still listening? last i heard was one of them signing > off, saying he couldn't reproduce the bug, and anyway he wasn't the author of > kio_fish. perhaps we're yelling up the wrong tree here? > > phani. Somebody has to fix this mess. You and I sure in the hell didn't create it! If it were up to me KDE would have forked into KDE3 and KDE4 and I would have happily continued to use KDE3. But instead, I spend a large part of my time writing bugs against basic functionality that never should have been broken in the first place. Somebody better be listening.... ;-)
201 votes! It is very unlikely this bug goes unnoticed...
Everyone: shouting won't help. Especially until we find out who's guilty for the breakage :-) Since debugging this the normal way seems difficult, I think we should collect data points and proceed scientifically. Could someone test (on a machine where the problem happens) KDE-4.1.x and KDE-4.2.x to see if it was working there? If we find at which version it broke, then we can easily identify the guilty commit. Alternatively (for those compiling from sources), svn up -r906580 inside kdebase/runtime/kioslave/fish/ and make install (and "killall kio_fish" before trying again). (Even better: svn-bisect, to do a binary search until the guilty commit between 906580 and HEAD). If it did work before the January commits, then my suspicion is that Thorsten Staerk shouldn't have unsubscribed from the bug... (cf the commits made for bug 147948). Sorry I can't spend more time on it right now (I'm currently at a customer site in Ireland).
(In reply to comment #74) > Everyone: shouting won't help. Especially until we find out who's guilty for > the breakage :-) no doubt about that. > Since debugging this the normal way seems difficult, I think we should collect > data points and proceed scientifically. > > Could someone test (on a machine where the problem happens) KDE-4.1.x and > KDE-4.2.x to see if it was working there? If we find at which version it broke, > then we can easily identify the guilty commit. Alternatively (for those > compiling from sources), svn up -r906580 inside kdebase/runtime/kioslave/fish/ > and make install (and "killall kio_fish" before trying again). (Even better: > svn-bisect, to do a binary search until the guilty commit between 906580 and > HEAD). sorry that i can't do that. i've got a dinosaur of a machine (single core athlon 1700) and a lousy internet connection. either installing previous versions or compiling from source would take me a whole day, which i don't have. i do remember though that everything was working fine while KDE 4.3 was still in alpha testing. either with the switch to beta 1 or shortly after fish protocol broke for me. sorry that i can't be of more help, but time, hardware, and internet access don't permit it. phani. PS: and no shouting from me; i'm happy with what i've got, KDE 4.3 & 3.5 in tandem.
> i do remember though that everything was working fine while KDE 4.3 was still > in alpha testing. either with the switch to beta 1 or shortly after fish > protocol broke for me. to make sure my memory doesn't trick me: i was the first one to report this bug, and for a long time nobody else seems to have noticed. at that time i was using "Version: 4.2.69 (using Devel)", as shown in the original report. that was a few days after i noticed the bug, and since then fish has never been working for me under KDE 4.3. doesn't that release no. tell you which commit was the culprit? phani.
I can confirm this.. It works fine with kde4.2.* for me. You can see no changes in 4.2 branches during the last months: http://websvn.kde.org/branches/KDE/4.2/kdebase/runtime/kioslave/fish/
(In reply to comment #77) > I can confirm this.. It works fine with kde4.2.* for me. > You can see no changes in 4.2 branches during the last months: > http://websvn.kde.org/branches/KDE/4.2/kdebase/runtime/kioslave/fish/ i meant to say that even in the beginning of KDE 4.3, during alpha testing, things were still working fine. unfortunately i didn't note down the actual release number when i noticd the bug, but from the date of the initial report, that could probably be calculated. phani.
btw.. if I remove the .fishsrv.pl from my remote server I can't login with fish anymore. So I mean he doesn't create this file.
Phani, since you were the first to notice this I took your report date and selected the last commit before that. Can you please do cd trunk/KDE/kdebase/runtime/kioslave/fish svn diff -c 946444 | patch -R and then recompile.
(In reply to comment #80) > Phani, > > since you were the first to notice this I took your report date and selected > the last commit before that. Can you please do > > cd trunk/KDE/kdebase/runtime/kioslave/fish > svn diff -c 946444 | patch -R > > and then recompile. please excuse my ignorance... what am i supposed to do, exactly? download the source for the whole kdebase (RC 2) from svn, apply the patch, and then compile the whole thing? or is it sufficient to just download kdebase/runtime/kioslave/fish, apply the patch, and then compile & install? any of these things will take a while, but i'm willing to do it. phani.
Am Samstag 18 Juli 2009 schrieb phanisvara das: > https://bugs.kde.org/show_bug.cgi?id=189235 > > --- Comment #81 from phanisvara das <phani00 gmail com> 2009-07-18 > 22:02:27 --- (In reply to comment #80) > > what am i supposed to do, exactly? download the source for the whole > kdebase (RC 2) from svn, apply the patch, and then compile the whole thing? > or is it sufficient to just download kdebase/runtime/kioslave/fish, apply > the patch, and then compile & install? As you said your version was "compiled from sources" I did not go any further, sorry. You need to build whole kdebase.
(In reply to comment #82) > As you said your version was "compiled from sources" I did not go any further, > sorry. You need to build whole kdebase. sorry, must have ticked the wrong box somewhere. never compiled kdebase from source, only small app.s now and then. i'll do it, but don't hold your breath...slow computer & slow internet connection.... phani.
(In reply to comment #80) svn diff -c 946444 | patch -R patching file fish.cpp Hunk #1 FAILED at 516. Hunk #2 FAILED at 533. Hunk #3 FAILED at 1437. Hunk #4 FAILED at 1473. 4 out of 4 hunks FAILED -- saving rejects to file fish.cpp.rej
Am Samstag 18 Juli 2009 schrieb sts@gmx.de: > https://bugs.kde.org/show_bug.cgi?id=189235 > > > > > > --- Comment #84 from <sts gmx de> 2009-07-18 22:42:20 --- > (In reply to comment #80) > > svn diff -c 946444 | patch -R > patching file fish.cpp > Hunk #1 FAILED at 516. > Hunk #2 FAILED at 533. > Hunk #3 FAILED at 1437. > Hunk #4 FAILED at 1473. > 4 out of 4 hunks FAILED -- saving rejects to file fish.cpp.rej Yeah, sorry, I broke it yesterday when I tried to make the code a bit more readable. Before the diff..patch command you need to call: svn up -r 998969
*** Bug 200736 has been marked as a duplicate of this bug. ***
Bug is still there. openSUSE 11.1 (i586) KDE: 4.2.96 (KDE 4.2.96 (KDE 4.3 RC2)) "release 142"
Bug is still there. Kubuntu 9.04 (x86) KDE: Version 4.2.98 (KDE 4.2.98 (KDE 4.3 RC3))
Fish is *working* for me in openSUSE 11.1 x86 4.2.98 (KDE 4.2.98 (KDE 4.3 RC3)) "release 148" On Sat, Jul 25, 2009 at 2:20 PM, Sebastian <catcher@vollbio.de> wrote: > https://bugs.kde.org/show_bug.cgi?id=189235 > > > Sebastian <catcher@vollbio.de> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |catcher@vollbio.de > > > > > --- Comment #88 from Sebastian <catcher vollbio de> 2009-07-25 15:20:19 > --- > Bug is still there. > Kubuntu 9.04 (x86) KDE: Version 4.2.98 (KDE 4.2.98 (KDE 4.3 RC3)) > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. >
(In reply to comment #89) > Fish is *working* for me in openSUSE 11.1 x86 please remove the .fishsrv.pl from your remote home dir and test it again.
(In reply to comment #89) > Fish is *working* for me in openSUSE 11.1 x86 > 4.2.98 (KDE 4.2.98 (KDE 4.3 RC3)) "release 148" *so it does for me.* i had to refresh once after getting the old error message, but that may have been sitting in the cache (?). after that konqueror connected w/o problem and copied files up & down from a remote server. thanks to whoever did whatever that (seems to have) got rid of that bug... phani.
(In reply to comment #90) > (In reply to comment #89) > > Fish is *working* for me in openSUSE 11.1 x86 > > please remove the .fishsrv.pl from your remote home dir and test it again. um...after removing that file, it *does not* work anymore. konqueror 3.5 crates a new one and works fine, but not 4.2.98 (148). phani.
> um...after removing that file, it *does not* work anymore. konqueror 3.5 crates > a new one and works fine, but not 4.2.98 (148). > > phani. trying again after a while i got connected eventually (refresh), but konq. doesn't copy files: same error as before: connection to...is broken. can't understand how it worked after the upgrade to release 148 (which didn't do anything to the fish file on the remote server, of course), but after removing that file, it's back to the old behavior--puzzled... phani.
> it's back to the old behavior--puzzled... behavior changed a little: after closing all konqerors i can connect to a remote host w/o further errors, copy _small_ files up & down, larger files from remote to local, but uploading works only for tiny files: 32 KB was working, 100 kB wasn't. sorry if that's useless info., but wanted to mention it, just in case. phani.
KDE 4.2.98 (KDE 4.3 RC3) on Ubuntu Jaunty Now remote editing with Kate works, but fish connection brakes frequently. I need to click save button 2 or 3 times before the file is effectively saved on the remote machine. Same behavior with or without ssh shared connections. Hope this helps.
using kde 4.3 (jaunty+http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu) I also get very fishy fish behaviour - this was completely allright in kde 4.2. Can't give much more info - but it's almost 100% reproducible by trying to upload bigger files...
*** Bug 202066 has been marked as a duplicate of this bug. ***
I just wanted to confirm this bug in Kubuntu Jaunty (KDE 4.2.98 (KDE 4.3 RC3)) 64 bits. When opening a fish URL I get (in console): "/usr/bin/konqueror(14001)" Error in thread 139838244951888 : "org.freedesktop.DBus.Error.ServiceUnknown - The name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files" "/usr/bin/konqueror(14001)" Error in thread 139838244951888 : "QLocalSocket::connectToServer: Invalid name" And Konqueror shows: Connection to Server Closed Unexpectedly Although a connection was established to XX.XX.XX.XX, the connection was closed at an unexpected point in the communication.
Im glad that SFTP works because this feature is broken...
confirming console output: "/usr/bin/konqueror(14001)" Error in thread 139838244951888 : "org.freedesktop.DBus.Error.ServiceUnknown - The name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files" "/usr/bin/konqueror(14001)" Error in thread 139838244951888 : "QLocalSocket::connectToServer: Invalid name" but these messages appear, when connection is established successfully, too! But when it fails I get the following additional output: QPainter::begin: Widget painting can only begin as a result of a paintEvent QPainter::translate: Painter not active QPainter::setClipRect: Painter not active QPainter::hasClipping: Painter not active QPainter::setPen: Painter not active QPainter::setBrush: Painter not active QPainter::drawRects: Painter not active These messages seem not to be serious or causing the fish-problem - but when I see this, I ask the developers: Did you ever watch for any debug output??? Bugs are not for filing bug reports, that nobody cares - bugs have to be eliminated. I cannot understand how you can release KDE 4.3 ignoring such a showstopper!!! This bug was first filed in April - so what did you do all the time (being more important than bug fixing)??? It's ok, when bugs appear in newly released software, but it is never ok, when bugs are ignored! I cannot accept an answer saying it is not reproducable. If you cannot reproduce, you did not check all descriptions that are listed here. I can reproduce failing connections on 4 PCs now... Everytime I did the same procedure as detailledly described again: * installing kubuntu 9.04 using the desktop CD for AMD64 * added the backports PPA including the PGP key, everything as described on www.kubuntu.org * sudo apt-get update * sudo apt-get upgrade * sudo apt-get dist-upgrade * then I removed -Rf "~/.kde" -> the next showstopper bug, without it KDE4.3 doesn't even start from beginning on... * restarted / logged in (now KDE4.3RC3) * used Konqueror with an URL like "fish://user@mydomain.de" * first time kwallet pops up and after kwallet is set up, fish fails * pressing F5 many times surrounds the problem - then you see some files and folders, but working is not possible because it fails again on saving any remote file... Sorry, but ignoring bugs makes me crazy, even though I thank the developers for creating such an overall experience with open source software, that is very positive in general.
(In reply to comment #100) > confirming console output: > This bug was first filed in April - so what did you do all the time (being more > important than bug fixing)??? great! people spend their time to produce software that you use for free, and then you get angry if they don't work the way you imagine they should. there's plenty more bugs which need to be fixed, and for some reason that eludes me this one can't easily be reproduced by everyone. would you like a couple developers drop by your place and figure things out on your computer (paying their own way, of course)? get real, man...phani.
Phanisvara, what you say make sense but it sounds as the typical argument ("developers spend time and you get a free software so don't complain and pay them if you want the bug fixed..."). Ok, that's right. However, I agree with comment #100 but would prefer to ask just a question: How is possible that KDE 4.3 is released with such a critical bug? It just shouldn't. If kio_fish doesn't work then this KDE version is (for me) worse than a pre-alpha version as it's mostly useless. IMHO, such critical bugs should stop a new release until they are fixed. How can you announce a new cool version of KDE while so critical regressions still exist? KDE's reputation is too important and shouldn't accept it (IMHO). Please don't take me wrong. Even if my comment could sound rude I try to be constructive. I really think that the common feeling of any KDE4 user is the same: How can be useful a KDE version in which common and required features just don't work at all? Regards.
(In reply to comment #102) > How is possible that KDE 4.3 is released with such a critical bug? It just > shouldn't. If kio_fish doesn't work then this KDE version is (for me) worse > than a pre-alpha version as it's mostly useless. IMHO, such critical bugs > should stop a new release until they are fixed. maybe we should move this to the forums and try to find out how many users are actually affected by this bug? certainly not all. would be interesting to get an idea for whom it works and for whom it doesn't. that way we also might get an idea what causes the bug, or what prevents it. phani.
i've posted a poll in the "discussions & opinions" forum, at http://forum.kde.org/viewtopic.php?f=15&t=63730&start=0. let's see if this appears to be wide-spread or rather isolated...
@phani: Please try to understand me. I want to help you. It is not my intend to make your work worse. I am not able to fix this bug, but if I could, I would try, search and fix it at very first priority. The only thing I can do is to file bug reports and it is very annoying that nothing seems to happen for several months. That is a point when I must ask myself, if it makes sense to file any further bugs in future, if nobody cares... It is my free time, too - when I test, when I write bug reports. So let us work together to get things right instead of block and ignore each's criticism. In post #100, I wrote all steps to reproduce this bug. I hope, somebody of the developers can use it for finding and fixing the bug...
(In reply to comment #105) > @phani: Please try to understand me. I want to help you. It is not my intend to > make your work worse. i'm sorry, i very much overreacted. what got me upset was the angry tone i perceived in your original post--and then i replied even more unfriendly. i've nothing to do with developing KDE; couldn't even manage to download the sourcecode for kdebase becaues of my lousy network connection. i'm only subscribed to this thread because i want to know what's going on with this bug, and if possible to help. criticizing you or your posts is none of my business. apart from that you and others here have got a point: fish is an important part of the KDE package, and if it doesn't work properly, that doesn't look good for KDE. again, i'm sorry. won't happen again. phani.
Using KDE 4.3.0 on Kubuntu Jaunty, the bug is still here. Fish connects but not working properly, SFTP doesn't work but this can be my problem. Thank you
Just tried with kde 4.3-0.1 and konqueror still fails. I conducted a test by opening kde3/konqueror and kde4/konqueror and typing the fish address to my office. kde3/konqueror connected immediately on the first try: http://www.3111skyline.com/download/openSUSE_bugs/kde4/screenshots/fish-konqueror-kde3-1st-try.jpeg Then tried the identical test with kde4/konqueror which failed giving the same: "The requested operation could not be completed Connection to Server Closed Unexpectedly" error: http://www.3111skyline.com/download/openSUSE_bugs/kde4/screenshots/fish-konqueror-kde4-1st-try.jpeg Any progress? Do you need more straces sent in? I'm happy to send anything else you think will help, but this bug just keeps dragging along without resolution. Let us know and I, and I'm sure others, will be happy to send in any data you need. Thanks.
> svn diff -c 946444 | patch -R Has anybody tried this yet? All I see is reports that it doesn't work with vanilla 4.3 branch, which still has that patch applied! Another commit worth inspecting: http://websvn.kde.org/?view=rev&revision=933202
Replying to #109: too many changes since that commit. Hunk #1 FAILED at 516. Hunk #2 FAILED at 533. Hunk #3 FAILED at 1437. Hunk #4 FAILED at 1473. 4 out of 4 hunks FAILED -- saving rejects to file fish.cpp.rej So I tried svn up -r946443 instead. And then copying the result into my kde-4.3 checkout since my machine with the problem uses 4.3 branch. And... it works!!! I'll need to find the equivalent rev in 4.3 branch and then do a svn-bisect to find the guilty commit, but no time right now.
SVN commit 1010416 by lukas: unbreak fish protocol by reverting r946444 (467 votes :) Confirmed to work by #fedora-kde and dfaure in Bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=516416 BUG: 189235 M +7 -15 fish.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1010416
I cannot understand the politics in this point. I updated to 4.3 not knowing this 5 months (!!) old bug and now I have to press the save shortcut about 10 to 20 times to save a file? We only use ssh connections to our servers, so please tell me how to work, when every saving of a file takes up to 2 minutes?
Oliver, use SFTP protocoll, it works. sftp://
It's fixed in the 4.3 branch for 4.3.1. For 4.3.0, use this patch: http://cvs.fedoraproject.org/viewvc/rpms/kdebase-runtime/devel/kdebase-runtime-4.3.1-fish.patch?revision=1.1&view=markup If you use binary packages, ask your distribution to apply the patch. In Fedora, the patch is already applied in kdebase-runtime-4.3.0-4.fc10/11/12.
SVN commit 1010928 by kkofler: unbreak fish protocol by reverting r946444 (467 votes :) Forward port revision 1010416 by lukas from 4.3. (I had to redo the patch by hand due to the whitespace edits.) CCBUG: 189235 M +6 -7 fish.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1010928
i've added information about the available patch to this thread in the openSUSE bug tracker: "fish:// In Dolphin reports 'Broken'" (https://bugzilla.novell.com/show_bug.cgi?id=512051). let's see if the patch gets applied for the repos at download.opensuse.org... phani.
patch has been applied to download.openSUSE repos and fish:// works again as it used to. (kdebase4-4.3.0-105.1) :) phani.
Working well on openSUSE KDE Version 4.3.00 (KDE 4.3.0) "release 155". Thank You very much for fixing it!
Created attachment 36420 [details] fish:// still broken - connection times out with document open The initial connection problem appears fixed, but the remainder of this bug is NOT fixed. Specifically, after a text file has been open for 15-30 minutes using the fish:// protocol to access the file on another box on the LAN, additional attempts to save the document result in the same "Connection Broken" message that was received originally. Please Re-open this bug. Making the connection is just the first part of a successful fish:// session. Being able to successfully save your changes is equally important. fish is timing out during the session making it just as unreliable as if you hadn't connected in the first place. At least then, you would know to use sftp instead. I'm glad we all jumped the gun and said "It's Fixed!" just because the connection was established. Truth of the matter is, it's not completely fixed. Good progress has been made, but there is still a significant problem with fish. Pre-kde4, I could be working on a document, go to sleep, let kde lock the session, wake up in the morning, unlock the screen, and my fish connection was still just as happy. You can't even make it 30 minutes before you are forced to "save as" somewhere else and then re-establish the fish connection.
On Tuesday 25 August 2009 03:49:01 David Rankin wrote: > The initial connection problem appears fixed, but the remainder of this bug is > NOT fixed. Specifically, after a text file has been open for 15-30 minutes > using the fish:// protocol to access the file on another box on the LAN, > additional attempts to save the document result in the same "Connection Broken" > message that was received originally. i didn't time any of my fish sessions, but think i've been connected longer than 15 min to the same document without problems. are you sure it's not the remote server that's timing out the connection? that happens to me if i open any SSH connection and it remains idle for some time. that would apply to fish as well. phani.
On Tuesday 25 August 2009 03:49:01 David Rankin wrote: > additional attempts to save the document result in the same "Connection Broken" to find out what causes the connection to break, you could edit the file .fishsrv.pl on the remote server. it contains a bunch of debug statements that are commented out by default. if these are un-commented, log files are written to the /tmp directory on the server that should show what causes the connecton to terminate. phani.
(In reply to comment #120) > are you sure it's not the > remote server that's timing out the connection? that happens to me if i open > any SSH connection and it remains idle for some time. that would apply to > fish as well. To avoid it, add the following lines to /etc/ssh/sshd_config in the server and restart sshd: TCPKeepAlive yes ClientAliveInterval 60
Created attachment 36426 [details] Additional Broken Connection Error The most frequently received Broken Connection dialog after the fish:// connection times out.
(In reply to comment #122) > (In reply to comment #120) > > are you sure it's not the > > remote server that's timing out the connection? that happens to me if i open > > any SSH connection and it remains idle for some time. that would apply to > > fish as well. > > To avoid it, add the following lines to /etc/ssh/sshd_config in the server and > restart sshd: > > TCPKeepAlive yes That shouldn't be required with a fish connection and document open. The only time that has ever been required before is for idle ssh connection left open in 'konsole'. With kde apps, the fish connection has always remained open in kde3. > ClientAliveInterval 60
(In reply to comment #124) > (In reply to comment #122) > > (In reply to comment #120) > > > are you sure it's not the > > > remote server that's timing out the connection? that happens to me if i open > > > any SSH connection and it remains idle for some time. that would apply to > > > fish as well. > > > > To avoid it, add the following lines to /etc/ssh/sshd_config in the server and > > restart sshd: > > > > TCPKeepAlive yes > > That shouldn't be required with a fish connection and document open. The only > time that has ever been required before is for idle ssh connection left open in > 'konsole'. With kde apps, the fish connection has always remained open in kde3. > > ClientAliveInterval 60 Case-and-point, On my box where the fish timeouts are occurring, /etc/ssh/ssh_config already contains: ServerAliveInterval 300 ServerAliveCountMax 15 Which is enough to keep ssh connection open permanently.... It's a *bug* in the fish protocal still. As much as we want to wish it away, it will still require a skilled developer to fix it. I can only tell you what is happened with fish and what I'm seeing that I never saw in kde3, I don't have the kde4 developer skills required to find the bug or fix it ;-)
David Rankin, while your issue definitely qualifies as a bug, it is a DIFFERENT bug than the one which got filed here, which is the KDE 4.3 regression (compared to 4.2). Your issue appears to have been there ever since KDE 4. Please file a separate bug report for your separate bug!
(In reply to comment #126) > David Rankin, while your issue definitely qualifies as a bug, it is a DIFFERENT > bug than the one which got filed here, which is the KDE 4.3 regression > (compared to 4.2). Your issue appears to have been there ever since KDE 4. > Please file a separate bug report for your separate bug! Will do, thank Kevin, I was working in Quanta just now, uploading files to the server. First 3-4 files went just fine, then the "fish protocol broken" error appeared again and would not reconnect. Something is broken.
(In reply to comment #126) > David Rankin, while your issue definitely qualifies as a bug, it is a DIFFERENT > bug than the one which got filed here, which is the KDE 4.3 regression > (compared to 4.2). Your issue appears to have been there ever since KDE 4. > Please file a separate bug report for your separate bug! Will do, thanks Kevin, I was working in Quanta just now, uploading files to the server. First 3-4 files went just fine, then the "fish protocol broken" error appeared again and would not reconnect. Something is broken.
On Thursday 27 August 2009 09:55:19 David Rankin wrote: > I was working in Quanta just now, uploading files to the server. First 3-4 > files went just fine, then the "fish protocol broken" error appeared again and > would not reconnect. Something is broken. where did you find quanta KDE 4? quanta uses KDE 3 libraries & protocols far as i know... phani.
I have opened https://bugs.kde.org/show_bug.cgi?id=205294 on the remaining issue. Any of you guys that are well versed on fish problems can pick it up there. Hopefully this is some simple regression introduced during the last fix. And, I am curious, what was it that was finally identified as being the issue that was fixed here? Thanks.
(In reply to comment #129) > On Thursday 27 August 2009 09:55:19 David Rankin wrote: > > I was working in Quanta just now, uploading files to the server. First 3-4 > > files went just fine, then the "fish protocol broken" error appeared again and > > would not reconnect. Something is broken. > > where did you find quanta KDE 4? quanta uses KDE 3 libraries & protocols far as > i know... > > phani. phani, It happens in kde4 kate and kwrite as well. I just happened to have quanta open when the last fish file upload failed so that's why it got used as the example ;-) Probably a poor choice, but it doesn't matter if it's a quanta upload or simply editing in kate, the fish connection is lost and your stuck... As for where quanta came from? /opt/kde3/bin/quanta
(In reply to comment #131) > It happens in kde4 kate and kwrite as well. I just happened to have quanta open > when the last fish file upload failed so that's why it got used as the example > ;-) Probably a poor choice, but it doesn't matter if it's a quanta upload or > simply editing in kate, the fish connection is lost and your stuck... > > As for where quanta came from? /opt/kde3/bin/quanta The thing is -- you say KDE 3 worked perfectly, and the behavior in KDE 4 is a regression, then say you are using quanta, which is a KDE 3 application (doesn't matter if the overall desktop is KDE 4, what matters is what each application uses), and you get this behavior, then either it is broken on both KDE 3 or KDE 4, or it might be something on your setup that causes both KDE 3 versions (which you said worked fine) and KDE 4 versions (which should be fine now) to fail.
Seems to be fixed in Kubuntu Backports PPA for KDE 4.3.1 (available since today). Thanks a lot!