Version: (using Devel) OS: Linux Installed from: Compiled sources Steps to reproduce: -open an ftp server with dolphin. -open a text file on it with kate or kwrite -change the file and save Result: -the file on ftp server was not changed, upon closing the application a dialog appears asking weather to upload the changes to server. Expected result: -the file on ftp server is changed when the save operation is performed. Everything works as expected if this is done by first opening kate and selecting file via file open dialog or by dragging and dropping file in existing kate window.
I understand that this is done mainly for compatibility with non-kde applications. Maybe it's possible to mark in file associations that this program can talk to KIO, or write it in the .desktop file...
*** Bug 222641 has been marked as a duplicate of this bug. ***
The sequence you describe above works flawlessly for me over ftp. What version of KDE are you running ? Do you still see this issue in the most recent releases of KDE ? And yes editing files over the network works by downloading the file locally and automatically uploading the modified file back as soon as you save your changes ; so unless you have some sort of network issues or file perimission problems on the server (cannot write the document), there is no reason why this would not work.
> The sequence you describe above works flawlessly for me over ftp. What version > of KDE are you running ? Do you still see this issue in the most recent > releases of KDE ? Currently i'm running 4.6. Yes, this issue is still here. > And yes editing files over the network works by downloading the file locally > and automatically uploading the modified file back as soon as you save your > changes ; so unless you have some sort of network issues or file perimission > problems on the server (cannot write the document), there is no reason why this would not work. I know how it works. Let's look at a normal behavior: http://voserver.net/s1.png - we open file. http://voserver.net/s2.png - it's opend transparently. All upload on saving done automatically. And on a wrong one: http://voserver.net/s3.png - but if we will open file through "open with". http://voserver.net/s4.png - (fr example text file in kate) we will see a local copy opened. http://voserver.net/s5.png - And only after closing kate we will be prompted whether to upload modified file or not. The second behavior is not transparent. And there was no such behavior in 4.2 as i remember. P.S. sorry for russian lang in screenshots.
(In reply to comment #4) > > The sequence you describe above works flawlessly for me over ftp. What version > > of KDE are you running ? Do you still see this issue in the most recent > > releases of KDE ? > > Currently i'm running 4.6. Yes, this issue is still here. > > > And yes editing files over the network works by downloading the file locally > > and automatically uploading the modified file back as soon as you save your > > changes ; so unless you have some sort of network issues or file perimission > > problems on the server (cannot write the document), there is no reason why this would not work. > > I know how it works. > Let's look at a normal behavior: > http://voserver.net/s1.png - we open file. > http://voserver.net/s2.png - it's opend transparently. All upload on saving > done automatically. > And on a wrong one: > http://voserver.net/s3.png - but if we will open file through "open with". > http://voserver.net/s4.png - (fr example text file in kate) we will see a local > copy opened. > http://voserver.net/s5.png - And only after closing kate we will be prompted > whether to upload modified file or not. > > The second behavior is not transparent. And there was no such behavior in 4.2 > as i remember. > > P.S. sorry for russian lang in screenshots. I get the same behavior if I choose Kate from the "Open With" content menu as well. Unless you open a remote file with a non-KDE application, you should not get such prompt. IOW, I still cannot duplicate the issue as you are describing it here. But then again I am not running KDE 4.6, but what will eventually become KDE 4.7 (4.6.41) from git.
(In reply to comment #4) > > The sequence you describe above works flawlessly for me over ftp. What version > > of KDE are you running ? Do you still see this issue in the most recent > > releases of KDE ? > > Currently i'm running 4.6. Yes, this issue is still here. > > > And yes editing files over the network works by downloading the file locally > > and automatically uploading the modified file back as soon as you save your > > changes ; so unless you have some sort of network issues or file perimission > > problems on the server (cannot write the document), there is no reason why this would not work. > > I know how it works. > Let's look at a normal behavior: > http://voserver.net/s1.png - we open file. > http://voserver.net/s2.png - it's opend transparently. All upload on saving > done automatically. > And on a wrong one: > http://voserver.net/s3.png - but if we will open file through "open with". > http://voserver.net/s4.png - (fr example text file in kate) we will see a local > copy opened. > http://voserver.net/s5.png - And only after closing kate we will be prompted > whether to upload modified file or not. > > The second behavior is not transparent. And there was no such behavior in 4.2 > as i remember. I see what you are saying now... 1.) Open a text document from an ftp site using "Open With" and entering kate. 2.) Modify the document. 3.) Close Kate without saving the document. 4.) When asked if you want to save the file before close, choose 5.) Kate closes and you get the prompt to upload the document some of the time, not always. If that is the problem, then I can reproduce it. No idea why I do not always get prompted with the upload dialog though. Needs to be investigated...
BTW, this is only a kate issue. If you repeat the steps in comment #6, but "kate" with "kwrite", you will not get the dialog to upload. To me that simply means it is kate's issue and not KIO's.
Sorry I forgot about this ticket. I found the source of the cause for this problem. It is in the code of the OpenWith dialog itself. Basically, attempting to open a remote text file through the OpenWith dialog by typing in "kate" results in the text file being opened with kate, but KDE treating the situation as if we opened the file with a non KDE application! That happens simply because the "Exec=" line in kate.desktop is "kate -b %U" where as we typed in "kate" only. That is enough for KOpenWith dialog to say the commands are not the same and not use kate.desktop to open the remote text file. Unlike kate.desktop, the "Exec=" line in kwrite.desktop does not contain any additional options and hence uses kwrite.desktop as a service to open the remote file.
So, will it be fixed? :)
(In reply to comment #9) > So, will it be fixed? :) Yes, it is on my TODO list. I will get to it at some point.
Git commit d27838a49e958c7c22eed8f0348ee3bccfb4e24e by Dawit Alemayehu. Committed on 28/06/2013 at 12:30. Pushed by adawit into branch 'master'. Correctly handle KDE executables typed into the OpenWith dialog. REVIEW: 111272 FIXED-IN: 4.11 M +10 -0 kdecore/services/kservice.cpp M +14 -0 kdecore/services/kservice.h M +28 -6 kio/kfile/kopenwithdialog.cpp http://commits.kde.org/kdelibs/d27838a49e958c7c22eed8f0348ee3bccfb4e24e