Version: 3.5.2 (using KDE KDE 3.5.2) Installed from: Gentoo Packages Compiler: gcc-4.1.0 OS: Linux In a script I want to use KDE's kio-slaves to open (remote) files. Therefore I let the user choose the file to edit via URL=kdialog --getopenurl ~ and then I want to use the command line application kioexec to let the user edit the file and upload the changes. I do this with $ kioexec $APP $URL And here's the bug: If $URL is a local file (file://...) it will be opened in $APP and after I finished editing, I get a popup asking if I want to upload the changes. No matter what I click ([upload] or [do not upload]), the file will be DELETED. That's absolutely unforgivable. If $URL is a remote file (fish://... for example) all works fine.
increasing severity due to data loss
Can still confirm with 3.5.5
SVN commit 614397 by mkoller: BUG: 127894 Don't ask for upload and do not delete a file if it's already a local file M +5 -8 main.cpp --- branches/KDE/3.5/kdelibs/kio/kioexec/main.cpp #614396:614397 @@ -238,7 +238,7 @@ i18n( "File Changed" ), KStdGuiItem::del(), i18n("Do Not Delete") ) != KMessageBox::Yes ) continue; // don't delete the temp file } - else + else if ( ! dest.isLocalFile() ) // no upload when it's already a local file { if ( KMessageBox::questionYesNo( 0L, i18n( "The file\n%1\nhas been modified.\nDo you want to upload the changes?" ).arg(dest.prettyURL()), @@ -254,13 +254,10 @@ } } } - else - { - // don't upload (and delete!) local files - if (!tempfiles && dest.isLocalFile()) - continue; - } - unlink( QFile::encodeName(src) ); + + // don't delete a local file, except it is defined to be temporary (with --tempfiles switch) + if ( !dest.isLocalFile() || tempfiles ) + unlink( QFile::encodeName(src) ); } //kapp->quit(); not efficient enough
This is a misuse of kioexec though, it's not supposed to be used for local files. Instead of using kioexec directly, you could use kfmclient exec, which does the right thing (but then using the mimetype associations; you can't use the app). Or you could use kioexec only for remote urls, like krun does.
> This is a misuse of kioexec though, it's not supposed to be used > for local files. Why not? Enabling kioexec for local files makes it a nice tool for scripting applications. > Instead of using kioexec directly, you could use kfmclient exec, > which does the right thing (but then using the mimetype associations; > you can't use the app). But that's not always the right thing to do, e.g. in a script you probably want to edit a file with $EDITOR (let's say vi) instead of kate, what the associations would use. > Or you could use kioexec only for remote urls, like krun does. Sure, and that's how I work around this problem currently. But again: KDE advertises to tie together scripts and the DE with cool things like DCOP and kdialog. In this respect it would be quite useful and logical if you could use kioexec with any path kdialog's file open dialog provides, without having to distinguish between local and remote files.