Comment 12 for bug 285998

An example of the gross failure of this is "rmdir ~/Videos" .

XDG tools will then notice the dir not missing, and change the definition to "$HOME/" .

Thereafter, media scanner will treat home as the Videos dir, and spend days of CPU scanning ~/sourcecode/projectsfoo/tests/10TB-of-video-files/* .

----

xdg-user-dirs should be an expression of the user's preferences, not an assertion of what was valid on the disk at some point in the past.

It does not matter whether the named variable's target existed on disk the last time it looked. Existence of the target is a function of time, the user's whims, and language. Apps using a XDG name at the user's request should handle the nonexistence by prompting the user to confirm intent, or merely create what it was asked to use.

Redefining the variable without any ability to discover or undo it is evil. Lying about the user's preference is wrong. Assuming apps can never mkdir() what they are asked to use is wrong.

----

In the mean time, apps should probably interpret XDG variables that are "$HOME/" (with significan trailing slash) as previously clobbered from this bug, invalid, and then prompt the user to re-set it to default or pick a location. If users pick their home, do not include the trailing slash in the value, and set it to "$HOME" instead.

The trailing slash is a good semaphore because any app is already expecting the returned value not to end in a slash. Most values from the XDG tool are like "/home/alice/Music", no trailing slash, so they append slash and the rest of their relative filename.