Bug 136630

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?

Confirmed on gentoo with plain kde 3.5.5
This is a very annoying and potentially dangerous bug.

I can confirm in KDE 3.5.5. The bug is grave due to dataloss.

And it is a regression!

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.]

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 );

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();

*** Bug 138279 has been marked as a duplicate of this bug. ***