naively renaming file associations can make them vanish and exhibit other strange behavior

Bug #115119 reported by Nick Lawson
6
Affects Status Importance Assigned to Milestone
KDE Base
Invalid
Medium
kdebase (Ubuntu)
Invalid
Low
Unassigned
kdebase-kde4 (Ubuntu)
Invalid
Low
Unassigned

Bug Description

Distro: Feisty Kubuntu, patched up to date.

Longer summary:
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.

Revision history for this message
Yuriy Kozlov (yuriy-kozlov) wrote :

Thank you for filing this bug. I can confirm that clicking the edit button in that dialog pops up the properties for the .desktop file, which is confusing. I think that what you should be editing is the Name field in the Application tab.
Marking low priority since this is a somewhat hidden feature/problem that's easy to avoid.
You should file a bug about this upstream at bugs.kde.org.

Changed in kdebase:
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
Yuriy Kozlov (yuriy-kozlov) wrote :

Same behavior in KDE4.

Changed in kdebase-kde4:
importance: Undecided → Low
status: New → Confirmed
Changed in kdebase:
importance: Wishlist → Low
Revision history for this message
Harald Sitter (apachelogger) wrote :

kdebase-kde4 was moved to kdebase in Intrepid

Changed in kdebase-kde4:
status: Confirmed → Invalid
Revision history for this message
Marcus Asshauer (mcas) wrote :

This bug has been reported to the developers of the software. You can track it and make comments here: https://bugs.kde.org/show_bug.cgi?id=171532

Changed in kdebase:
importance: Undecided → Unknown
status: New → Unknown
Changed in kdebase:
status: Unknown → New
Revision history for this message
In , Marcus Asshauer (mcas) wrote :

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.

Changed in kdebase:
status: Confirmed → Triaged
Revision history for this message
Jonathan Thomas (echidnaman) wrote :

Hi there!

Thanks for reporting this bug! Your bug seems to be a problem with the KDE program itself, and not with our KDE packages. But don't worry! This issue is being tracked by the KDE developers at: http://bugs.kde.org/show_bug.cgi?id=171532
Once fixed in KDE, it will be included in Kubuntu once the KDE version the fix is in in reaches Kubuntu.

Thanks!

Changed in kdebase (Ubuntu):
status: Triaged → Invalid
Changed in kdebase:
importance: Unknown → Medium
Revision history for this message
In , Andrew-crouthamel (andrew-crouthamel) wrote :

Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!

Changed in kde-baseapps:
status: New → Incomplete
Revision history for this message
In , Andrew-crouthamel (andrew-crouthamel) wrote :

Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version?

Thank you for helping us make KDE software even better for everyone!

Changed in kde-baseapps:
status: Incomplete → New
Revision history for this message
In , Justin Zobel (justin-zobel) wrote :

Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!

Changed in kde-baseapps:
status: New → Incomplete
Revision history for this message
In , Bug-janitor (bug-janitor) wrote :

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Revision history for this message
In , Bug-janitor (bug-janitor) wrote :

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!

Changed in kde-baseapps:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.