Version: (using Devel) Installed from: Compiled sources Steps to reproduce: 1) cut some files 2) paste them on another directory 3) go back to the original directory 4) undo the operation with CTRL+Z or by the edit->undo menu action the un-cutted files will have a different icon. On the next screenshot you can see the file "test1", "test2" and "test3" which has been cutted and bring back with undo. Before cutting icons was equal to "test4" and "test5".
Created attachment 25367 [details] un-cutted files
Very interesting issue :-) Can you tell me which MIME-type your files test1, test2, ... have? I assume when pressing "reload" the icons will be fixed. Is this correct?
yes, after reloading all is ok. I've reproduced even creating some empty files.
Here using: Qt: 4.4.3 KDE: 4.1.85 (KDE 4.1.85 (KDE 4.2 Beta2)) kdelibs svn rev. 899058 / kdebase svn rev. 899058 on ArchLinux x86_64 - Kernel 2.6.27.8 I've created some empty files (with ".txt" extension) using "touch". This files have an "text" icon After cutting and undoing the cut operation, The cutted files have the same "text" icon (they aren't "empty")
.txt makes the mimetype determination say "those are text files". Better not use extensions, to reproduce the original report. I can reproduce it indeed (using "for i in test{1,2,3,4,5}; do echo foo > $i ; done"). Strange that "undo" generates the bug, but not moving back the file by hand. The code that generates the "cut" icon is the problem, but where is that code? Peter? I thought there was some DolphinIconManager or something? Can't find it.
(i'm only online per iphone -> short reply) the code for cut items is in kfilepreviewgenerator in kdelibs. i've svn access again on the 1st of january and will take care for this :-)
Hm, I've problems to reproduce the issue... I did the following: 1. Open Dolphin in ~ 2. Create text files like in comment #5 by for i in test{1,2,3,4,5}; do echo foo > $i ; done 3. Cut items test4 and test5 4. Go into directory ~/Temp 5. Press paste 6. Go into directory ~ 7. Select "Undo Move" However the icons are not "empty", but indicate a text (see attachment). Has something changed in the meantime or do I something wrong?
I can still reproduce it (r905373)... but wait... are you using previews enabled? I'm not using previews.
Created attachment 29925 [details] Correct (?) result
Update: I just added the attachment I mentioned in comment #7 (I accidently added it to a wrong bug report). @FiNeX: > I can still reproduce it (r905373)... but wait... are > you using previews enabled? I'm not using previews. I did not use previews, very strange... I'll try it again today, maybe it is a timing problem.
Created attachment 30032 [details] bug still there I tried the exact steps from Peter in comment 7, and the bug happened again. SVN trunk r907015.
The bug seems to be in kfileitem, it finds the mimetype application/octet-stream for these files (which makes sense as a first guess from the extension, but not as final mimetype)... I guess what's missing is the delayed mimetype determination for those new files.
Ah. Found it. Mimetype is determined, but cached icon isn't cleared out. Another way to see this bug: cut one file, then rename it with another (known) extension -> the icon won't change, but it does normally (when the icon is not cut). KDirModel bug, on my way to fixing it.
SVN commit 907835 by dfaure: Clear the cached icon (preview or "cut icon") when the mimetype changes (due to delayed mimetype determination or due to renaming the file). BUG: 164185 M +13 -0 kdirmodel.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=907835
SVN commit 907837 by dfaure: Clear the cached icon (preview or "cut icon") when the mimetype changes (due to delayed mimetype determination or due to renaming the file). The fix will be in 4.2. CCBUG: 164185 M +13 -0 kdirmodel.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=907837
Thanks David!!
Good, the patch works fine :)