On upgrade from Guinness, my ZIP icon has broken. I have /dev/sda4 (the ZIP device) in console.perms, and have checked that it is owned by the console user, and that 'mount /mnt/zip' works fine. Here's the fstab line: /dev/sda4 /mnt/zip auto noauto,owner 0 0
Created attachment 8639 [details] Here's the kdelnk file that no longer works
Here's the failure mode: Konqueror window opens with URL http://navigation.realnames.com/resolver.dll?action=navigation&realname=file%3A&charset=iso-8859-1&providerid=180&fallbackuri=http%3A//www.google.com/search%3Fq%3D%5C1 Modal dialog window opens with: Unsupported action listDir
When creating a new icon, it works fine. Old Desktop files should be upgraded, IMHO.
Created attachment 8640 [details] Newly-created file that does work
Does running desktopconv fix this for you?
This defect is considered MUST-FIX for Florence Release-Candidate #1
No, desktopconv made things much worse. I replaced my newly made Zip file in /home/tim/Desktop with the Zip.kdelnk that I attached to this bug, and ran desktopconv from my home directory. I ended up with a Desktop subdirectory within my existing Desktop subdirectory, and so only one icon on my Desktop. After removing one level of directories, I am left with a Desktop/Zip. It doesn't work, with similar symptoms as before the change. I'll attach it.
Created attachment 8659 [details] desktopconv result
desktopconv converts KDE 1.x-ish config files to 2.x - running it after having changed config files to 2.x can't work. Also, your KDE 1.x config is odd (no mountpoint listed). Are you sure this ever worked? Is /dev/sda4 listed in fstab?
Why doesn't it spot that and just stop then, rather than f**king up the Desktop subdir? Yes, of course I'm sure this worked. '/mnt/zip' shows up in the properties dialog; presumably it gets that info from my /etc/fstab. Can you reproduce this or not?
Yes, but since I don't have a ZIP drive, I couldn't tell for sure whether or not the original file worked. The "Mountpoint=" line *is* odd. I'll fix up desktopconv now.
I don't think this is Zip-drive specific; a spare partition (or even a loopback mount) might trigger it.
This is fixed in 2.0.20010201-2. I've rewritten desktopconv to take care of these things (and it won't break existing KDE 2.x configs anymore).
For the record, I was able to reproduce this on a machine with a VFAT partition rather than a ZIP drive. After running desktopconv (no upgrades from fisher), this time I got 'The desktop entry file ... has no Type=... entry' when clicking on the icon.