[Bug]: installing onto NilFS2 filesystem (without support for extended attributes) fails

[martinvahi]

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?

Other (specify below)

Linux distribution version

Q4OS 5.2 Aquarius stable, "uname -a" includes a string "Debian 6.1.52-1 (2023-09-07)"

What architecture are you using?

x86_64

How to reproduce

#Initially the flatpak is not installed. 
# "/" is on a separate partition that uses ext4 that 
# includes the following at its mount parameters at /etc/fstab: noatime,nodiratime,user_xattr 
# "/home" is on a separate partiton that is formatted to NilFS2 file system.
# /etc/fstab moun parameters of the NilFS2 based "/home": noatime,nodiratime
# NilFS2 does not support file system extended parameters, so adding the "user_xattr" probably does not make sense.
#
# As root:
apt-get install flatpak

# as plain user:
flatpak --user remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak remote # to see, what got added
flatpak remote-ls # to see a list of packages

flatpak --user install  flathub  com.jetbrains.IntelliJ-IDEA-Community  # gives the error, installation fails
# Installation with the above command succeeds after the folders
#     $HOME/.cache/flatpak
#     $HOME/.local/share/flatpak
# have been replaced with symlinks to folders at the ext4 based "/" partition.
# After a successful install the application starts wit the command:
flatpak  run  com.jetbrains.IntelliJ-IDEA-Community 

Expected Behavior

I expect the installaction of the Flatpak packages to work regardless of which file system is used on Linux. From reliability, user experience, point of view the applications should just install without the end user having to be aware that some file systems support "somethign" like "extended attributes" and some filesystems do not.

A workaround might be that the data that gets written to extended file attributes, is written to some SQLite database file, where one column of a one of the tables contains file paths, which might be reversed to give the SQLite a chance to find them faster, like:

ABCD -->  DCBA

The string reversal explained by using Bash and standard command-line tools:

echo "ABCDE"  |  rev
# outputs to console: "EDCBA"

Actual Behavior

Flatpak package installs only, if file system supports extended attributes.

Additional Information

The reason, why I use NilFS2 at "/home" partition is that it is way more reliable for retaining data than the ext4.
The ext4 is good for scenarios, where there are a lot of temporary files, like compiling programs,
but NilFS2 is good for storing data that that has to be retained and does not need to change that extensively.
For example, deletion operation at NilFS2 partition only adds to the journal and the actual HDD/SSD space is freed
only after a daemon reads the journal and decides to actually free up the HDD/SSD space that
the deleted files occupied.

That explains, why my setup is that "/home" is formatted as that quite slow, but reliable, NilFS2 and
all building, more extensive data processing, is done at some other partition that has ext4.
As of 2023_09 my recommendation for preparing computers for "ordinary end users",
"office workers", is to use NilFS2 at "/home" partition, because that way a power-cut
won't destroy the end users' data.

Thank You for reading this bug report :-)

[smcv]

gives the error, installation fails

What error?

[smcv]

If I remember correctly, flatpak remote-add --user (installing into ~/.local/share) requires extended attributes, but flatpak remote-add (installing into /var/lib/flatpak) does not. If that's correct, then a workaround would be to install apps system-wide (which is the default) rather than on a per-user basis.