1) start dolphin, go to /tmp 2) create a file (right click, create new -> text file) and call it "ONE" 3) select it, copy and paste it on the same directory 4) you will be prompted that the file already exists and you can auto-rename 5) select to auto-rename it. It will be called "ONE_1" 6) paste it again: it will not ask you again if you want to rename, auto-rename or overwrite (like before), but it will paste a file called: "file:⁄⁄⁄tmp⁄ONE"
I have Dolphin 1.1 under KDE 4.1.4 I could not reproduce it. I get the message file exists and been asked to rename it as always at 6)
I've forgot to specify that the bug is reproducible in current trunk (r966196) with Qt 4.5.1
I cannot reproduce in KDE 4.2.3. Each subsequent paste gives a file ONE_N where N is the first available integer.
The bug is still available on current trunk (just reproduced with r973477). It has been introduced in the development version, not in 4.2 branch.
I see Finex, sorry.
Is this a kdelibs or a dolphin bug?
I can reproduce this bug here using: Qt: 4.5.1 (qt-copy 971295) KDE: 4.2.91 (KDE 4.2.91 (KDE 4.3 >= 20090609)) kdelibs svn rev. 982117 / kdebase svn rev. 982118 on ArchLinux i686 - Kernel 2.6.29.4
I tracked this down to CopyJob (ugh): From "CopyJobPrivate::addCopyInfoFromUDSEntry": The second time we paste the file: Both "entry.stringValue(KIO::UDSEntry::UDS_NAME);" and "entry.stringValue(KIO::UDSEntry::UDS_URL);" are empty. This causes this code to be executed: " // Here we _really_ have to add some filename to the dest. // Otherwise, we end up with e.g. dest=..../Desktop/ itself. // (This can happen when dropping a link to a webpage with no path) if (destFileName.isEmpty()) { destFileName = KIO::encodeFileName(info.uSource.prettyUrl()); } " And the whole current path (encoded) is used as destFileName (so you get /tmp/file:///tmp/foobar) It seems this is related to KDirLister(Cache?), as if we use an already existing file (which should be on listercache) instead a new created one, pasting that file everytime will raise the "conflicting filename" dialog every time. BTW: also, in the second paste of the new created file I noticed this on shell: "dolphin(18447)/kio (KIOJob) KIO::CopyJobPrivate::statCurrentSrc: fast path! found info about KUrl("file:///tmp/ccc") in KDirLister" This is not present during the first file paste Another interesting thing: Copying to the same location a new created file in that session OR a file which already existed before opening Dolphin will bring two *different* dialogs: In the first case, only a "auto_rename" dialog will appear. In the second one, a more detailed one will appear (showing both files metadata) I'm adding David to the CC as this seems related to KIO jobs and DirLister. Thanks
*** Bug 195607 has been marked as a duplicate of this bug. ***
*** Bug 196642 has been marked as a duplicate of this bug. ***
*** Bug 197114 has been marked as a duplicate of this bug. ***
*** Bug 197406 has been marked as a duplicate of this bug. ***
*** Bug 197775 has been marked as a duplicate of this bug. ***
SVN commit 987912 by dfaure: Fix misbehavior of copy+paste+paste due to the "use cached item" optimization going wrong (and getting an almost-empty udsentry without name) Kudos to Dario Andres who did the whole investigation! Fix will be in 4.3. BUG: 192185 M +3 -1 copyjob.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=987912
SVN commit 987929 by dfaure: Found the underlying cause for the empty cached KFileItem after creating a file using knewmenu: the KDirWatch fileDirty triggered a KFileItem::refresh (which makes the kfileitem still usable, but clears its UDSEntry so the optimizations in copyjob can't benefit from it). Fixed by removing pending updates to dir/file when dir itself is being relisted anyway. With unittest. Not sure about backporting this one, it's only a rather small performance gain (since it could only happen with local files anyway). The case where it would make the biggest speed difference would be pasting 1000 items, then selecting them again and pasting them somewhere else. CCBUG: 192185 M +20 -5 kio/kdirlister.cpp M +1 -1 kio/kdirlister_p.h M +65 -3 tests/kdirlistertest.cpp M +1 -0 tests/kdirlistertest.h WebSVN link: http://websvn.kde.org/?view=rev&revision=987929
I've just read on the Qt changelog of 4.5.2 about some fixes on QFile and QTemporaryFile: - QFile and QTemporaryFile * Fixed a leak of file descriptors in QTemporaryFile::rename, introduced in 4.5.1 * [165920] QFile::copy leaves the source file open after the file has been copied. * [191467] & [252293] QFile::copy of resource files to the file system fails on Windows. * [197857] QFile::copy of resource files leaves temporary files on file system. * [248223] QTemporaryFile: Access denied error when (re-)opening through QFile interface. * [252659] QTemporaryFile::rename may leave source file behind. Are those fixes related with this bug?
After upgrading to Qt 4.5.2 but without upgrading to new KDE with fix for this bug it still happens, so probably fixes in Qt are unrelated.
Good to know, Thanks Emdek :-)
*** Bug 198295 has been marked as a duplicate of this bug. ***
FiNeX: file copying in kde uses KIO (so that it is network transparent), so QFile::copy is not used. See comments #14 and #15 for the fixes to this bug ;-)
Hi I can confirm this bug in rc 1 of kde 4.3. KDE Infos: Qt: 4.5.0 KDE: 4.2.95 (KDE 4.2.95 (KDE 4.3 RC1)) kde4-config: 1.0 Compiler: gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3 Kernel: Linux alpha 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 22:12:12 UTC 2009 x86_64 GNU/Linux Dist: No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 9.04 Release: 9.04 Codename: jaunty Date: Mon Jul 6 15:32:57 CEST 2009
Manuel, is this bug also reproducable in the released KDE 4.3? If yes, we need to reopen it.