Bug 136630

Summary: 'Save As' behaviour change
Product: kio Reporter: James Spencer <jamessp>
Component: kfileAssignee: Carsten Pfeiffer <pfeiffer>
Severity: grave CC: bluedzins, faure, sven.burmeister
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
Latest Commit: Version Fixed In:

Description James Spencer 2006-11-01 14:20:36 UTC
Version:            (using KDE KDE 3.5.5)
Installed from:    Debian testing/unstable Packages
Compiler:          G++-4.1.1-13 (Debian Unstable) 
OS:                Linux

Since the kde-3.5.5 packages entered Debian there has been an annoying behaviour change in the 'Save As' boxes.

To reproduce:
1. Open any app that uses 'Save As'. Proceed to use 'Save As'.
2. If you start in the Documents folder, and hit the 'up arrow' to home, or the home button, 'Documents' will still be selected in blue. If you enter any other directory in home, then go 'back home' the previous folder will be selected. The same goes for any folder in the tree... Knowing the last folder you were in isn't bad, but...
3. When you click 'Save' it will ask you 'do you want to overwrite this file'. It will ask you this whenever a folder is highlighted from a move in the file-system, even with a file-name specified. Testing with koffice revealed that saying 'yes' didn't overwrite the folder, but instead left a zero byte backup file bearing the previously selected folder's name. Saying 'no' will pop up the 'save as' box again, with no folder selected, allowing you to save with the specified name.

This behaviour is annoying, and could lead to data loss (By being careless). The 'Save As' box should save in the current directory, with the specified file name, NOT WITH THE NAME OF THE PREVIOUSLY SELECTED DIRECTORY.
Comment 1 S. Burmeister 2007-01-14 12:18:24 UTC
I can confirm this too. Why is this not yet assigned/fixed? Since it was reported a log time before the 3.5.6 freeze it should be fixed in it, should it not?
Comment 2 Marius 2007-01-14 12:24:43 UTC
Confirmed on gentoo with plain kde 3.5.5
This is a very annoying and potentially dangerous bug.
Comment 3 Stefan Monov 2007-01-14 12:25:55 UTC
I can confirm in KDE 3.5.5. The bug is grave due to dataloss.
Comment 4 S. Burmeister 2007-01-14 12:29:08 UTC
And it is a regression!
Comment 5 James Spencer 2007-01-15 02:26:12 UTC
Just to be clear, the bug is still here. There have been several updates in Debian unstable and I was hoping the Debian KDE folks would get it but no luck. I've simply started to take a shot of hard liquor every time it happens. The good news is the bug is far less annoying, the bad news is I haven't been able to drive in several months :) [I kid, and I know this is less than helpful.]
Comment 6 David Faure 2007-01-15 10:21:13 UTC
SVN commit 623695 by dfaure:

Revert 589847, selecting the last directory when going up leads to bugs since its name is being used when pressing OK
(even if a filename was typed previously to navigating down and back up). The right fix would be to give the lineedit
precedence over the selected item but this look a bit more involved, I'll let Carsten do that :)
BUG: 136630
CCBUG: 103540
CCMAIL: Carsten Pfeiffer <pfeiffer@kde.org>

 M  +1 -1      kdiroperator.cpp  
 M  +2 -1      kdiroperator.h  

--- branches/KDE/3.5/kdelibs/kio/kfile/kdiroperator.cpp #623694:623695
@@ -74,7 +74,7 @@
     KDirOperatorPrivate() {
         onlyDoubleClickSelectsFiles = false;
         progressDelayTimer = 0L;
-        dirHighlighting = true;
+        dirHighlighting = false;
         config = 0L;
         dropOptions = 0;
--- branches/KDE/3.5/kdelibs/kio/kfile/kdiroperator.h #623694:623695
@@ -517,7 +517,8 @@
      * I.e. when you go from /home/gis/src to /home/gis, the item "src" will
      * be made the current item.
-     * Default is on.
+     * Default is off, because this behavior introduces bug #136630.
+     * Don't enable until this bug is fixed.
 	// ### KDE4: make virtual
     void setEnableDirHighlighting( bool enable );
Comment 7 David Faure 2007-01-15 13:41:30 UTC
SVN commit 623752 by dfaure:

Propagate error case from closeArchive() to KArchive::close(). Otherwise we get no error when trying
to save to a path that is in fact a directory.
This isn't enough to fix koffice though, it also ignores errors from KArchive::close() :(
CCBUG: 136630

 M  +1 -1      kio/karchive.cpp  
 M  +15 -0     tests/karchivetest.cpp  
 M  +1 -0      tests/karchivetest.h  

--- trunk/KDE/kdelibs/kio/kio/karchive.cpp #623751:623752
@@ -176,7 +176,7 @@
         delete m_dev; // we created it ourselves in open()
     if ( d->saveFile ) {
-        d->saveFile->finalize();
+        closeSucceeded = d->saveFile->finalize();
         delete d->saveFile;
         d->saveFile = 0;
--- trunk/KDE/kdelibs/kio/tests/karchivetest.cpp #623751:623752
@@ -392,6 +392,21 @@
     QCOMPARE( arr, zipMimeType );
+void KArchiveTest::testCreateZipError()
+    // Giving a directory name to kzip must give an error case in close(), see #136630.
+    // Otherwise we just lose data.
+    KZip zip( QDir::currentPath() );
+    bool ok = zip.open( QIODevice::WriteOnly );
+    QVERIFY( ok );
+    writeTestFilesToArchive( &zip );
+    ok = zip.close();
+    QVERIFY( !ok );
 void KArchiveTest::testReadZip()
     // testCreateZip must have been run first.
--- trunk/KDE/kdelibs/kio/tests/karchivetest.h #623751:623752
@@ -35,6 +35,7 @@
     void testTarMaxLength();
     void testCreateZip();
+    void testCreateZipError();
     void testReadZip();
     void testZipFileData();
     void testZipCopyTo();
Comment 8 Stephan Kulow 2007-01-16 12:09:14 UTC
*** Bug 138279 has been marked as a duplicate of this bug. ***