[Bug 171532] New: naively renaming file associations can make them vanish and exhibit other strange behavior

[mcas]

http://bugs.kde.org/show_bug.cgi?id=171532

           Summary: naively renaming file associations can make them vanish
                    and exhibit other strange behavior
           Product: kde
           Version: 4.1.0
          Platform: Ubuntu Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: unassigned-bugs at kde.org
        ReportedBy: kubuntu at asshaueronline.de


Version:            (using KDE 4.1.0)
OS:                Linux
Installed from:    Ubuntu Packages

This bug was first reported on the ubuntu bug tracker under:
https://bugs.edge.launchpad.net/ubuntu/+source/kdebase/+bug/115119

If you click the button (tool button) when viewing the properties of a file, or
in the edit file types dialog within konqueror, or within the kde file types
settings dialog, if you change the 'name' of the .desktop file, it removes the
association, and dissappears! The problem is that its not clear that you're
renaming the .desktop file, and the disappearing causes all sorts of strange
behavior (depending on the association which just vanished), and also kde
doesnt seem to realise that its been renamed, so it doesnt rebuild its menus or
something. Either way, it appears to vanish - and recreating it behaves oddly
too.

To illustrate this, here is an example of how to reproduce. Lets say Joe User
has installed a tool called SOMETOOL and he'd like to associate them with
ms-windows executables.

1. Find a ms-windows executable (ie, a file compiled with mono or an installer
or something)
2. Edit the file's properties (right click, properties) then choose Edit File
Type (the little tool button)
3. Application Preference Order lists the applications to use. User clicks ADD
and types in SOMETOOL. He clicks ok. It adds SOMETOOL at the top.
4. (Here's where it messes up). User decides he doesnt like seing SOMETOOL in
the list and would prefer that it showed up as "Some Useful Tool" when he right
clicks to open the file. So the user selects SOMETOOL from the application
preference order dialog and clicks 'edit'
5. The dialog that pops up is actually editing the desktop file. This is not
really all that clear. The user sees SOMETOOL in the edit box, so he assumes
that controls the name displayed to him. So he changes that to "Some Useful
Tool" and clicks "OK". Then closes all the dialogs and assumes it worked. KDE
says "updating system settings"
---> Unbeknownst to the user, kde has renamed the desktop file to "Some Useful
Tool.desktop" without updating its cache or whatever. This means that the file
type has disappeared from the "open with" dialog! In fact, in some cases, I've
seen it remove ALL file types from that mimetype, having overridden them! This
has led to "unknown mimetype - application/octet-stream" which is a rather
serious issue.
---> The file type has also disappeared from the properties and associations
dialog if you right click on the file and choose properties -> edit file type.
Its just GONE.
---> If you try to add the same file type again, it will call it something like
SOMETOOL-2 and other wierd things can happen. It will leave the renamed
filetype in your desktop .hidden folder. Rebooting causes other behavior.

Once when I did this, it wiped my application/executable mimetype (or something
similar) and applications like amarok would pop up hundreds of dialogs about
missing mimetype at launch time. Very irritating. to fix it, I had to go to
kde's mimetype editor and manually create application/octet-stream or whatever,
to restore it. This happened without me ever deleting any mimetypes.


-- 
Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.