Doesn't run likely due to 64 bit inodes on big disks

[simpz]

Hi

This Flatpack doesn't run for me the reason for which is likely 64 bit inodes, which Acrobat Reader doesn't support. 64 bit inodes are the default on XFS filesystems >1GB.

% flatpak run --share=network com.adobe.Reader

Gtk-Message: 15:16:04.945: Failed to load module "canberra-gtk-module"

Gtk-Message: 15:16:04.946: Failed to load module "pk-gtk-module"

Acroread was unable to create the directory .adobe in your home directory.`

There may be a permission problem with the parent directory.

Acroread was unable to create the directory /home/csimpson/.adobe in your home directory.

There may be a permission problem with the parent directory.

Acroread was unable to create the directory /home/csimpson/.adobe in your home directory.

There may be a permission problem with the parent directory.

Acroread was unable to create the directory /home/csimpson/.adobe in your home directory.

There may be a permission problem with the parent directory.

Acroread was unable to create the directory /home/csimpson/.adobe in your home directory.

There may be a permission problem with the parent directory.

Acroread was unable to create the directory /home/csimpson/.adobe in your home directory.

There may be a permission problem with the parent directory.

Acroread was unable to create the directory /home/csimpson/.adobe in your home directory.

There may be a permission problem with the parent directory.

I do have my homedirs on large disks with XFS.

Lots of information and a solution here: https://www.mjr19.org.uk/sw/inodes64.htmlSdk

On this same system I have this working on a local install of Acrobat 9.5.5 that uses the above websites proloaded library.

/usr/local/bin/fix32 /usr/local/packages/Adobe/Reader9/bin/acroread "$*"

There would be no harm in preloading this library on systems not using 64 bit inodes and will help future proofing this package to some extent (as much as that's possible).

[hmenke]

 * WARNING!! USE AT OWN RISK -- AUTHOR ACCEPTS NO RESPONSIBILITY
 * IF THIS DESTROYS YOUR DATA, OR CAUSES ANY OTHER FORM OF INCONVENIENCE
 * OR DISASTER. AUTHOR RECOMMENDS YOU DO NOT USE IT.

Not sure whether that's a good idea...

[simpz]

To be fair, most Open Source sofware says some variation of this, and a lot of commercial software has similar warning, its a short piece of code and looking at what it actually does should provide some reassurance.

[konradmb]

@simpz AUTHOR RECOMMENDS YOU DO NOT USE IT. is not an usual warning :smiley:

So as I understand, what that lib does is to return completely fake inode number (xor the top 32 bits of the inode number with the bottom 32 bits), right? So when Acrobat uses that inode for saving somewhere, it could overwrite some unrelated files? Is it proven it doesn't use inode numbers?

So either we use inode64.so or can we:

1. Recompile some lib with _FILE_OFFSET_BITS=64? Does the stat call come directly from acroread?
2. Does more robust workarounds exist? FUSE, overlayfs? Containers, cgroups, qemu?

[Erick555]

Does more robust workarounds exist? FUSE, overlayfs? Containers, cgroups, qemu?

None of those would run inside flatpak.

[konradmb]

None of those would run inside flatpak.

I don't see why qemu wouldn't run in flatpak :stuck_out_tongue:

[simpz]

My reading of the wrapper code is it does nothing if the inode values are 32 bit, you are correct it fakes up a 32 bit inode.

The wrapper code only replaces stat and readdir, and I believe it's very rare to care about the inodes these return.

Loading and Saving seems to work fine from acrobat with this, as it likely just uses file/pathnames.

I believe the broken code is in the Adobe shipped code, so can't be fixed.

[konradmb]

Ok, so given that there are no alternatives available, this is what I propose:

• Patch inode64.c as to not return fake xor inode, but to return some number that would hard fail when using it.
• To be double sure, only preload it when 64-bit inodes detected.

What do you think?

PS What even are the ways to use the inode number for, like in Linux without root privileges?

[simpz]

Sounds like a great idea.

Ok, so given that there are no alternatives available, this is what I propose:

* Patch inode64.c as to not return fake xor inode, but to return some number that would hard fail when using it.

I wonder what that number would be, I wonder if zero would be good (but might look like a fail, not sure). But maybe if this value is unused, zero would work fine.

* To be double sure, only preload it when 64-bit inodes detected.

Not sure how to detect 64 bit inodes being in use on all file systems. I think that might be tricky. There are ways of seeing this from root, but tune2fs for ext4 and xfs_info. Or you can see from the output of mount, but this only seems to cover local filesystems. And NFS mounts don't show this. especially if the automounter is being used all mounts aren't in place when a program starts (also true of USB devices etc).

To be honest this is where I have most often seen this issue with Acrobat Reader, it's NFS homedirs, big corporate NAS's they are all inode64

PS What even are the ways to use the inode number for, like in Linux without root privileges? With these two call all we came up with was hard link detection. So most programs likely don't care.

Not being very familiar with Flatpak, I wonder if there is a way of passing a startup param or config setting to this container (do we even say that with Flatpak) to apply the workaround every time if you need it? This as a safe option.