Bug 127894 - kioexec deletes local files (data loss)
Summary: kioexec deletes local files (data loss)
Status: RESOLVED FIXED
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR major with 1 vote (vote)
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-23 19:04 UTC by Tassilo Horn
Modified: 2006-12-18 14:34 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tassilo Horn 2006-05-23 19:04:27 UTC
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.
Comment 1 Chris Howells 2006-05-24 05:03:08 UTC
increasing severity due to data loss
Comment 2 Martin Koller 2006-12-17 16:39:07 UTC
Can still confirm with 3.5.5
Comment 3 Martin Koller 2006-12-17 17:12:43 UTC
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
Comment 4 David Faure 2006-12-18 14:17:13 UTC
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.
Comment 5 Tassilo Horn 2006-12-18 14:34:55 UTC
> 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.