mv or rm of any XDG user dir causes its definition to change to wrong, oversimple $HOME/

Bug #285998 reported by komputes
96
This bug affects 13 people
Affects Status Importance Assigned to Milestone
mediascanner2
Fix Released
Undecided
Unassigned
mediascanner2 (Ubuntu)
Fix Released
Undecided
Unassigned
xdg-user-dirs (Ubuntu)
Confirmed
Low
Chad Miller

Bug Description

$ rmdir ~/Videos
...
$ mkdir ~/Videos

Hours later, find apps doing crazy things in home directory.

During the elided period between rmdir and mkdir, if the XDG functions were run, the user's intent is forever lost, and its value is set to the user's home directory.

Apps can not rely on XDG functions not to lie about what the user wants. It prefers to say what exists, not now when the app is accessing it, but when the XDG functions ran. It does not provide a file descriptor for an
open_at(2) call. It provides a stale, text name of what used to exist on disk, and often not even what the user wanted.

Related branches

Revision history for this message
Michael Nagel (nailor) wrote :

i see this clearly as a bug, see newly added duplicates.

important comments from there:

----------------------------
i have deleted my templates folder and nautilus does not handle this very well.
clicking on "Go->Templates" brings me to my home folder.

(that is at least consistent with
XDG_TEMPLATES_DIR="$HOME/"
line from .config/user-dirs.dirs)

however this setup is not very useful because i most certainly do not want to have my templates in my home folder (or put it the other way round: all my files as a template). and secondly, it does not work, i.e. even the files that are in my home folder are not available as templates...

i suggest that a non-existent template dir should not be changed to $HOME and i should be offered some assistance when clicking on "Go->Templates" in this case.
----------------------------

----------------------------
for future reference: i wrote up how to fix an accidentally deleted folder:
http://nailor.devzero.de/blog/archives/26-fix-broken-gnomenautilus-template-folder.html
----------------------------

Michael Nagel (nailor)
Changed in xdg-user-dirs (Ubuntu):
status: New → Confirmed
Revision history for this message
Jesse Johnson (holocronweaver) wrote :

I am a relatively new Ubuntu user and have the same problem. I deleted my Templates folder, thinking it was superfluous like the Music, Video, etc. folders, but as I began to use Ubuntu I realized that a document template feature existed in the right-click menu and I wanted use it. My first instinct was to search in the templates right-click menu for assistance, but none was found. My next action was to check the Help and Support manual, which specifies that you simply have to create documents in $HOME/Templates. I tried recreating the Templates folder and putting a document in it with no result. If I was a novice to computers, this would be my "I need to reinstall my OS" or "I need to call my computer savvy nephew" moment. Since I am no novice, I checked out Ubuntu's bug system and lo' and behold several bug reports on this issue exist accompanied by a solution for those with a smidge of Linux skills.

I think this is a problem that an ordinary person could be expected to accidentally cause by fiddling with their home directory (after all, for many new users that folder is a sandbox). To me the best solution is to implement an 'assistance' option in the right click templates menu for someone to reestablish their templates directory in the event that XDG_TEMPLATES_DIR="$HOME/". This would help both computer novice and Ubuntu newcommer alike. Of course, this may not be simple from a programming viewpoint, so my solution may not be feasible as the code stands.

In the short term, help offered when using Go->Templates may be of use, but I believe that most users will not look here as, from experience, I have found that few users even realize there is a "Go" menu in Windows, much less in Ubuntu.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

 * Is this reproducible?
 * If so, what specific steps should we take to recreate this bug?

 This will help us to find and resolve the problem.

Changed in xdg-user-dirs (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
Revision history for this message
Sebastien Bacher (seb128) wrote :

The description is not clear, what do you try to do? is the issue with nautilus or the xdg directories?

Revision history for this message
angem1 (angem1) wrote : Re: [Bug 285998] Re: Deleting ~/Templates and rebooting makes a change in ~/.config/user-dirs.dirs

Hello Sebastien.
I don't understand why the description of the bug seems unclear to you, but
I explain again
(actually I think this bug is already fixed, but check me since I am not
sure):
After deleting the auto-generated folders in the user home directory like :
Templates, Videos, Pictures, Documents (not sure about the exact names),
restarting the computer and recreating them, the ubuntu system won't
recognise them, especially the Templates folder as the folders to look up
for templates and other files...
The solution for this bug, is to edit the ~/.config/user-dirs.dirs file and
modify the directories
to match the formerly deleted directories.

Thanks for your bother !

2009/10/15 Sebastien Bacher <email address hidden>

> The description is not clear, what do you try to do? is the issue with
> nautilus or the xdg directories?
>
> --
> Deleting ~/Templates and rebooting makes a change in
> ~/.config/user-dirs.dirs
> https://bugs.launchpad.net/bugs/285998
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Revision history for this message
Omegamormegil (omegamormegil) wrote : Re: Deleting ~/Templates and rebooting makes a change in ~/.config/user-dirs.dirs

To duplicate, move your Templates folder to the Desktop, and run xdg-user-dirs-update in the terminal. You will see: "/home/nate/Templates was removed, reassigning TEMPLATES to homedir"

Changed in xdg-user-dirs (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Omegamormegil (omegamormegil) wrote :

My Templates folder is on removable media which fstab mounts automatically. When I boot and the media is removed, xdg-user-dirs-update runs and is moving the path from ~/Templates to ~ when it sees that the folder is missing. To fix the problem, I had to manually edit .config/user-dirs.dirs to correct the path to the templates folder.

I don't see any reason for xdg-user-dirs-update to change the path just because the folder is temporarily missing or moved. The expected behavior would be that moving the Templates folder would break the right click > Create Document functionality, and moving it back would fix the problem, but after xdg-user-dirs-update runs (every boot) the functionality is broken permanently which is very confusing to the user.

Changed in xdg-user-dirs (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
summary: - Deleting ~/Templates and rebooting makes a change in ~/.config/user-
- dirs.dirs
+ Missing ~/Templates folder and rebooting makes a change in
+ ~/.config/user-dirs.dirs
Revision history for this message
Omegamormegil (omegamormegil) wrote : Re: Missing ~/Templates folder and rebooting makes a change in ~/.config/user-dirs.dirs

"do you expect it to use a non available directory? not a bug"

Sebastian,

This is a bug, not because I expect it to use a non available directory, but because the change made by xdg-user-dirs-update to ~/.config/user-dirs.dirs is PERMANENT (unless you manually edit the file the fix the path).

ie, this is a Permanent response to a Temporary condition. My ~/Templates folder is temporarily unavailable, but xdg-user-dirs-update permanently changes the path, permanently breaking the functionality of creating documents from my templates via a right click.

The process should automatically check if the Templates folder comes back, and fix the path.

summary: - Missing ~/Templates folder and rebooting makes a change in
- ~/.config/user-dirs.dirs
+ A misplaced ~/Templates folder over a reboot permanently changes the
+ TEMPLATES path in ~/.config/user-dirs.dirs
Revision history for this message
Mahendra Tallur (mahen) wrote : Re: A misplaced ~/Templates folder over a reboot permanently changes the TEMPLATES path in ~/.config/user-dirs.dirs

I just encountered this issue as well. I understand why it occurs (in order to stop pointing to a directory that doesn't exist anymore), but I guess it's an issue nonetheless.

Indeed :

- I deleted the Templates ("Modèles" in my case) directory because I thought it was useless.
- When I figured out a friend of mine was looking for such a feature, I tried to re-create the Templates directory but it didn't behave as expected
- Expected behaviour : files copied to ~/Templates are added to the "New File" Nautilus menu
Obtained behaviour : the menu remains empty

So I guess the "xdg-user-dirs-gtk-update" app executed during each Gnome session should also check whether one expected directory (in this case Templates) has been created or removed.

To fix it I had to manually modify the ~/.config/user-dirs.dirs file.

Cheers !

Revision history for this message
Omegamormegil (omegamormegil) wrote :

From http://www.freedesktop.org/wiki/Software/xdg-user-dirs under the Settings heading:

    Note: To disable a directory, point it to the homedir. If you delete it it will be recreated on the next login.

For some reason, deleted folders are being automatically pointed to the homedir, which disables them. They are not recreated on the next login as intended.

Revision history for this message
Joshua Riffle (rampageai) wrote :

This may be related to this bug or possibly a separate bug. I can re-file this comment if necessary. I have created a script in the /etc/X11/Xsession.d folder that is numbered to run *before* the xdg-user-dirs-update script. My script detects whether or not the Desktop and Documents folders have been replaced with an appropriate folder symbolic link of the same name and if it they haven't then it replaces them. However, the user-dirs-update script apparently "detects" that the actual folders have been replaced and forces nautilus to use the $HOME folder in ~/.config/user-dirs.dirs for both of them instead of the appropriate symlink. The strange part is it will only complain that they have been replaced with symlinks if xdg-user-dirs-update is run from within a script or sourced, but it will actually give the correct folders if it is run directly from the command-line. If it is run from the command-line it will *not* update the user-dirs.dirs file but if I delete the user-dirs.dirs file completely it will replace it and if it is sourced or run within the script then it does actually seem to update the user-dirs.dirs file though with $HOME instead of the correct folders.

Changed in xdg-user-dirs (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
Chad Miller (cmiller)
summary: - A misplaced ~/Templates folder over a reboot permanently changes the
- TEMPLATES path in ~/.config/user-dirs.dirs
+ mv or rm of an XDG user dir causes it to reset to $HOME/
summary: - mv or rm of an XDG user dir causes it to reset to $HOME/
+ mv or rm of any XDG user dir causes its definition to change to wrong,
+ oversimple $HOME/
Revision history for this message
Chad Miller (cmiller) wrote :

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.

Chad Miller (cmiller)
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mediascanner2 (Ubuntu):
status: New → Confirmed
Chad Miller (cmiller)
Changed in xdg-user-dirs (Ubuntu):
assignee: nobody → Chad Miller (cmiller)
Changed in mediascanner2:
status: New → In Progress
Changed in mediascanner2 (Ubuntu):
status: Confirmed → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mediascanner2 - 0.105+15.04.20150122-0ubuntu1

---------------
mediascanner2 (0.105+15.04.20150122-0ubuntu1) vivid; urgency=low

  [ Jussi Pakkanen ]
  * Add blacklist functionality and use it to block music playlists.
    (LP: #1384295)
  * Skip scanning of special directories if they point to user home dir.
    (LP: #285998)
 -- Ubuntu daily release <email address hidden> Thu, 22 Jan 2015 10:18:10 +0000

Changed in mediascanner2 (Ubuntu):
status: In Progress → Fix Released
Changed in mediascanner2:
status: In Progress → Fix Released
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.