[Bug]: error: mkdir(/home/user/.var/app/org.torproject.torbrowser-launcher/data): Too many levels of symbolic links

[TNTBOMBOM]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug that matches the one I want to file, without success.
• If this is an issue with a particular app, I have tried filing it in the appropriate issue tracker for the app (e.g. under https://github.com/flathub/) and determined that it is an issue with Flatpak itself.
• This issue is not a report of a security vulnerability (see here if you need to report a security issue).

Flatpak version

1.14.4

What Linux distribution are you using?

Debian

Linux distribution version

12.4

What architecture are you using?

x86_64

How to reproduce

user@host:~$ flatpak --user install com.github.micahflee.torbrowser-launcher
Looking for matches…

Info: app com.github.micahflee.torbrowser-launcher branch stable is end-of-life, in favor of org.torproject.torbrowser-launcher branch stable
Replace? [Y/n]: y

org.torproject.torbrowser-launcher permissions:
    ipc       network              fallback-x11         pulseaudio      wayland      x11
    dri       file access [1]      dbus access [2]

    [1] xdg-config/kdeglobals:ro, xdg-download
    [2] com.canonical.AppMenu.Registrar, org.kde.KGlobalSettings, org.kde.kconfig.notify


        ID                                         Branch         Op         Remote         Download
 1. [✓] org.torproject.torbrowser-launcher         stable         i          flathub        10.3 MB / 8.5 MB

Installation complete.
user@host:~$ flatpak run org.torproject.torbrowser-launcher 
error: mkdir(/home/user/.var/app/org.torproject.torbrowser-launcher/data): Too many levels of symbolic links

Expected Behavior

Should run properly.

Actual Behavior

Doesnt run.

Additional Information

No response

[smcv]

Which of these directories:

/home/user/.var/app/org.torproject.torbrowser-launcher/data

is a symbolic link? (I'm guessing at least the last one?)

[TNTBOMBOM]

user@host:~$ ls -l /home/user/.var/app/

lrwxrwxrwx 1 user user   34 Jan 27 13:49 com.github.micahflee.torbrowser-launcher -> org.torproject.torbrowser-launcher
lrwxrwxrwx 1 user user   34 Jan 26 11:42 org.torproject.torbrowser-launcher -> org.torproject.torbrowser-launcher

user@host:~$ ls -l /home/user/.var/app/org.torproject.torbrowser-launcher/
ls: cannot access '/home/user/.var/app/org.torproject.torbrowser-launcher/': Too many levels of symbolic links

symbolic link loop. From the output, the symbolic link org.torproject.torbrowser-launcher inside /home/user/.var/app/ is pointing to itself.

[chrisawi]

Did you previously have com.github.micahflee.torbrowser-launcher installed? i.e. did ~/.var/app/com.github.micahflee.torbrowser-launcher already exist?

In that case, flatpak run should have renamed the directory and created a symlink from the old name.

What's really curious is that the self-symlink is older than the proper old->new one. flatpak shouldn't have attempted any migration if the new path already existed (even as a broken symlink). How do those timestamps line up with your actions?

[TNTBOMBOM]

Did you previously have com.github.micahflee.torbrowser-launcher installed? i.e. did ~/.var/app/com.github.micahflee.torbrowser-launcher already exist?

Yes, and it doesnt get deleted anymore if the new version of the TB-launcher been installed and then removed:

user@host:~$ flatpak uninstall org.torproject.torbrowser-launcher --delete-data  


        ID                                          Branch          Op
 1. [-] org.torproject.torbrowser-launcher          stable          r

Uninstall complete.
Delete data for org.torproject.torbrowser-launcher? [y/n]: y
user@host:~$ cd /home/user/.var/app/
user@host:~/.var/app$ ls
com.github.micahflee.torbrowser-launcher  

In that case, flatpak run should have renamed the directory and created a symlink from the old name.

Yes but seems there is a loop when this happen?

How do those timestamps line up with your actions?

What happened is this:

TB-launcher was initially maintained by Micah Lee. I installed the TB-launcher from his repository. Later, the project shifted to the Tor Project, and the repository upgraded fine automatically within Flatpak.

Later, I decided to uninstall the TB-launcher and reinstall it. However, when I tried to install it again, I used Micah Lee's (old) repository. That's when I encountered the issue you see now.

[AsciiWolf]

To be honest, I am not sure how this happens. I have tested the torproject-launcher Flatpak EOL rebase on multiple systems (all running Fedora 39 with btrfs file system) and there was no issue. The old app dir got properly renamed and a symlink to the old name was created.

[chrisawi]

I recently encountered this (entirely by accident) with Ptyxis after its eol-rebase from Prompt. I renamed ~/.var/app/org.gnome.Ptyxis.Devel and then flatpak run moved the symlink it had created and made a new one. This explains the ages of the symlinks; moving a file doesn't change its mtime.

A plausible scenario to trigger this without manually removing the directory is:

1. Have the original app installed, and run it at least once
2. Let it be eol-rebased to the new name via flatpak update
3. Run the app again so the app data is migrated
4. Uninstall it with --delete-data, which leaves the symlink behind
5. Install it again using the original name, re-establishing the eol-rebase info in the deploy data
6. Try to run the app, which fails because flatpak migrated the symlink

I suspect this is exactly what happened to @TNTBOMBOM

My plan is to check the symlink target and skip migration it if it points to the new app ID. Additionally, it probably makes sense for --delete-data to clean up symlinks of known previous IDs.