Version: 2.3.1 (using KDE 3.3.1, (3.1)) Compiler: gcc version 3.3.5 (Debian 1:3.3.5-3) OS: Linux (i686) release 2.6.10-rc3 When opening a file on a remote location using an io slave like fish: or smb:, if kates window becomes inactive and then active again kate notices that the local copy of the file was deleted (by the io slave i guess) after transfer was completed, and complains about it with the error dialogue: 'File Was Deleted on Disk' I would expect that when working on a file on a remote system, that you don't get this error. If kate needs a local copy, just save it without asking, but remember to delete the temporary copy when kate is closed, or if you save it locally with Save As. I think this is actually a regression from KDE 3.2.x where it worked ok, as far as I know. There was the tiny problem in KDE 3.2.x that when you opened a remote file, the first transfer would hang and you had to cancel it, however it would then reload the file automatically and it would work fine from then on. I think in fixing that, a one or two of new and related bugs appeared. See also: Bug #95973: Regression: Save no longer uploads file when working over io slave (normal) Bug #87617: kio file gives confusing error message when opened file is deleted on disc (normal) Bug #92337: Can't configure the "file changed of disk" reloading behaviour (preference for kate 2.2 behaviour) (wishlist)
This bug is also in KDE 3.3.2.
Kate only applies the disk modification check to files with a URL for which KURL::isLoaclFile() returns true. If some protocols have such URLs but KDirWatch can't work with the directory, kate will fail. That would be a kio bug. I have no network, so I can't test if this is true. Anyone else?
If you right click on a file in konquerer which you are looking at through the fish protocol, and select open with and open it with kate, then kate (or the io-slave) downloads the file to the temporary local folder and after which it is opened in kate. You can see that kate is really working locally by looking at the window title. It is using the temporary name instead of the real name. If kate works the way you say, then the url check would return true I guess, which means that it will complain when it finds the temporary file suddenly missing. It seems that kate forgets that it is working on a remote file instead of a local file somewhere during the load process. I feel that this is related to bug #95973 which you also commented on. Clearly if kate has forgotten that it is working on a remote file it won't update it either, when you press save. Personally I think that this problem has appeared because of a change that was made in 3.3 in order to fix another issue which caused the first download of the file from the remote location to always fail. You always had to cancel the first download, after which kate would open with an empty document, and then reload the remote file, succeding this time. The first time the document loaded it was most likely really saved locally, but kate would not know about this, so it would just hang at 100% downloaded forever. It seems likely that the fix meant that kate now looks locally for the file it first downloads. Unfortunatly it also forgets that the file really came from somewhere else. In that case the fix would seem to be have kate still be aware of the first locally downloaded copy, but also remember to switch back to the remote url when it has opened and loaded the local temporary file into memory. This would fix both this issue and bug #95973 at the same time.
On Sunday 23 January 2005 20:00, andersa@ellenshoej.dk wrote: > ------- Additional Comments From andersa ellenshoej dk 2005-01-23 20:00 > ------- If you right click on a file in konquerer which you are looking at > through the fish protocol, and select open with and open it with kate, then > kate (or the io-slave) downloads the file to the temporary local folder and > after which it is opened in kate. Well, your system must be somehow misconfigured. I just was given a account on a remove system, and it works perfectly well here. The file is opened in it's remote location, and the remote URL is in the window, and pressing ctrl + s updates the remote file. You could check that you have 'kwrite %U' and 'Kate %U' -- notice the capitol U's -- in the exec lines in your commands. You can see them for example in the menu editor, or when you select the application from the tree in the 'open with' dialog. -anders
Now I have only been able to test with cvs HEAD, so I ask some friend in #kate: [20:35:56] <sredna> dh__: Are you haging 3.3.2? [20:36:03] <sredna> Having [20:36:09] <dh__> yes [20:36:16] <dh__> I run it all day... [20:36:47] <sredna> Could you confirm that loading remote files via fish:// works in both kate and kwrite? [20:37:13] <dh__> sredna: can I use localhost ? [20:37:27] <dh__> or must it be a remote-file [20:37:34] <sredna> He. That I don't know [20:37:38] canllaith can confirm this for 3.3.2 [20:38:01] <canllaith> :) It was 3.3.1 I discovered fish:/ and I use it every single day since then
On Sunday 23 January 2005 20:37, Anders Lund wrote: > Well, your system must be somehow misconfigured. I just was given a account Of couse that's possible. It is a fairly recent debian sarge install upgraded to unstable. It's just over 1 month old I think. > on a remove system, and it works perfectly well here. The file is opened in > it's remote location, and the remote URL is in the window, and pressing > ctrl + s updates the remote file. Here it is first downloaded to a temporary file and then opened in kate. Changes are made to the local copy. > You could check that you have 'kwrite %U' and 'Kate %U' -- notice the > capitol U's -- in the exec lines in your commands. You can see them for > example in the menu editor, or when you select the application from the > tree in the 'open with' dialog. This is what i have. Still it downloads the file locally before opening it. I even tried creating a brand new user and starting kde with that user. Same thing. Anders
On Sunday 23 January 2005 21:04, andersa@ellenshoej.dk wrote: > Of couse that's possible. It is a fairly recent debian sarge install > upgraded to unstable. It's just over 1 month old I think. Since the problem seems to be non-existing on standard kde installations (source, slackware packages or gentoo ebuilds with the users i talked to today) maybe you should post a bug report for debian. You could try to open a file using kwrites open dialog, you can simply type in the URL in the filename field (fish://user@host.org/path/to/file). -anders
Very well. Closing..
Well, I'd still be happy to help you get it working. But it is hard to fix a problem that seems to not exist on mine or other kate developers systems. May I suggest that you join the #kde or #debian-kde channels on the freenode.net irc network? I'll be in the #kde and #kate channels with nick 'sredna'