"Name" key value in desk. entry spec collides with file names, could misguide users?

Kalle Vahlman kalle.vahlman at gmail.com
Sun Mar 13 09:00:26 EET 2005

On Sun, 13 Mar 2005 01:26:34 +0100, Diego Calleja <diegocg at teleline.es> wrote:
> Problem 1: What user sees is not what is there:
>    How to Reproduce:
>    Step 1) Create a foo.desktop file with key Name="foo"
>    Step 2) Create another foo.desktop file in the gnome panel with key Name="bar"
>    Step 3) Try to drag panel's foo.desktop file to user's desktop.
>    Bug: He'll get a warning because he's trying to overwrite "foo.desktop" with
> "foo.desktop". User was just seeing "foo" and "bar". He'll never know that "foo"
> and "bar" had the same name and he won't know how to drag panek's foo.desktop
> reliably.

This is annoying when encountered, true, but how often would a user
see this? The "user way" of creating .desktops is through some UI,
which at least on GNOME creates a random name for it. The application
provided .desktops could have this problem, but why would you have two
of them in the same place (and not want to overwrite)?

And for those that do create .desktops by hand should be aware of
this, since they should be familiar with the spec already.

> Problem 2: What user executes is not what he sees
>    How to reproduce:
>    Step 1) Create a whatever.desktop file
>    Step 2) Set Name="Natalie Portman Nude.jpg"
>    Step 3) Set Run=evil-executable
>    Bug: This is a well-learnt lesson from "another OS", where user thinks he's
> opening a image and he's running a evil program, I don't think it needs more
> explanations.

So this is somehow different from the situation that I decide to name
my newest malware executable as "Natalie Portman Nude.jpg" and users
click on it trying to view it with the default viewer?

The problem is not new, and is not fixed by removing the most useful
feature of the whole spec (human readable and translatable names for

The only way to Be Sure (tm) currently is to only use
software/anything from a trusted source.

Kalle Vahlman, zuh at iki.fi

More information about the xdg mailing list