desktop-launch moved my files around!

[NoraCodes]

This is a big problem for me. My home directory has Videos, Music, etc linked to my bulk storage media and this script just moved all my files out of their hierarchy and into my home directory!

[kenvandine]

@jhenstridge can you please take a look at this?

[NuclearNemo]

This has happened to me as well for two times during the last two weeks when trying to launch the snap of Chromium. Luckily I had a backup, but it caused some work to restore everything. Really eerie experience, when all of a sudden my files began to get messed up.

My setup is as follows: The / and /home directory of my main installation (Kubuntu 20.04) are on a SSD drive, while there is also a much bigger HDD as a second drive where I store all of my "bigger" data (photos, music, videos etc.). The HDD partition is mounted unter /mnt/my_hdd and there are symbolic links in my home directory to its directories (e.g. ~/photos is a symlink to /mnt/my_hdd/photos).

Now what desktop-launch seemed to do was to move the files and directorys of this symlinked directories (HDD) to my home directory (SSD). E.g. ~/photos/* (actually stored on /mnt/my_hdd/photos/) was moved to ~/*. Subdirectories like photos/album1 were kept intact, but all the content of the "top level folders" of my HDD (music, videos, photos, ...) got mixed up together in my home directory. In both cases I noticed there's something going wrong and managed to kill desktop-launch after a short time, otherwise, it would have filled up all the small space on my SSD.

Can I provide any further information to help to debug this? I'm not sure how I can reproduce this, since in all cases except the two ones recently Chromium startup worked just fine. Fortunately I'm using Chromium only for testing purposes, so I don't launch it that often and can make btrfs snapshots before doing so and taking that risk again.

Kind regards, Jan

[NoraCodes]

I just want to point out that, since it's now essentially impossible to opt out of using snaps on Ubuntu, this seriously needs to be either fixed or documented - preferrably fixed. File hierarchy metadata is really important, and erasing it without user intervention isn't really acceptable.

[oSoMoN]

I tried to reproduce the problem in a VM with what I hoped would be a similar setup, but no luck.

However the code in https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L209 looks like it might be a potential cause for problems like this:

# If we aren't creating new links, check if we have content saved in old locations and move it
for ((i = 0; i < ${#XDG_SPECIAL_DIRS[@]}; i++)); do
  old="${XDG_SPECIAL_DIRS_INITIAL_PATHS[$i]}"
  new="${XDG_SPECIAL_DIRS_PATHS[$i]}"
  if [ -L "$old" ] && [ -d "$new" ] && [ `readlink "$old"` != "$new" ]; then
    mv -vn "$old"/* "$new"/ 2>/dev/null
  elif [ -d "$old" ] && [ -d "$new" ] && [ "$old" != "$new" ] &&
       (is_subpath "$old" "$SNAP_USER_DATA" || is_subpath "$old" "$SNAP_USER_COMMON"); then
    mv -vn "$old"/* "$new"/ 2>/dev/null
  fi
done

This requires further investigation.

[oSoMoN]

@NuclearNemo, @NoraCodes: could you please share the contents of ~/.config/user-dirs.dirs and ~/snap/chromium/current/.config/user-dirs.dirs (replace "chromium" by the name of the snap with which you're observing the issue) ?

[NuclearNemo]

Here:

~/.config/user-dirs.dirs

# This file is written by xdg-user-dirs-update
# If you want to change or add directories, just edit the line you're
# interested in. All local changes will be retained on the next run.
# Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped
# homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an
# absolute path. No other format is supported.
# 
XDG_DESKTOP_DIR="$HOME/Schreibtisch"
XDG_DOWNLOAD_DIR="$HOME/"
XDG_TEMPLATES_DIR="$HOME/"
XDG_PUBLICSHARE_DIR="$HOME/"
XDG_DOCUMENTS_DIR="$HOME/Dokumente"
XDG_MUSIC_DIR="$HOME/"
XDG_PICTURES_DIR="$HOME/"
XDG_VIDEOS_DIR="$HOME/"

~/snap/chromium/current/.config/user-dirs.dirs:

# This file is written by xdg-user-dirs-update
# If you want to change or add directories, just edit the line you're
# interested in. All local changes will be retained on the next run.
# Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped
# homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an
# absolute path. No other format is supported.
# 
XDG_DESKTOP_DIR="/home/jan/Schreibtisch"
XDG_DOWNLOAD_DIR="/home/jan/"
XDG_TEMPLATES_DIR="/home/jan/"
XDG_PUBLICSHARE_DIR="/home/jan/"
XDG_DOCUMENTS_DIR="/home/jan/Dokumente"
XDG_MUSIC_DIR="/home/jan/Musik"
XDG_PICTURES_DIR="/home/jan/Bilder"
XDG_VIDEOS_DIR="/home/jan/Videos"

I have to admit I hadn't noticed before that my ~/.confi/user-dirs.dirs is rather "non-standard" with almost everything pointing directly to my home dir... Why that is or why I may have changed it like this I can't remember - it's possible that it has been that way for years.

It seems interesting to me that both files are not consistent in the way that in ~/snap/chromium/current/.config/user-dirs.dirs some XDG dirs point to different locations - perhaps this is (one of) the trigger(s) for this bug?

[NoraCodes]

I have to admit I hadn't noticed before that my ~/.confi/user-dirs.dirs is rather "non-standard" with almost everything pointing directly to my home dir... Why that is or why I may have changed it like this I can't remember - it's possible that it has been that way for years.

For me, that happened when/if I opened Nautilus with the drive my directories were symlinked to disconnected.

[NuclearNemo]

I have to admit I hadn't noticed before that my ~/.confi/user-dirs.dirs is rather "non-standard" with almost everything pointing directly to my home dir... Why that is or why I may have changed it like this I can't remember - it's possible that it has been that way for years.

For me, that happened when/if I opened Nautilus with the drive my directories were symlinked to disconnected.

Might be a possible cause in my case as well since it happened a few times that my system was running without my HDD mounted (so that the symlinks in ~/ to its directories were temporarily broken).

[NuclearNemo]

I'm a bit worried that this bug will bite me or other people when Firefox as Snap will bei rolled out in 22.04 to a large number of users.

[NoraCodes]

Just wanted to chime in and say that yes, in fact, I think this will happen to anyone with their user-dirs configured across filesystem boundaries. I'm done with Ubuntu and am going to unsubscribe from this but it's pretty clearly a critical bug.