Summary: | Using io slave kate complains 'File Was Deleted on Disk' | ||
---|---|---|---|
Product: | [Applications] kate | Reporter: | Anders E. Andersen <andersa> |
Component: | general | Assignee: | KWrite Developers <kwrite-bugs-null> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 2.3.1 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Anders E. Andersen
2004-12-29 14:29:31 UTC
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' |