Bug 164185

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