`chown some_user a_file` and `chgrp some_group a_file` do not keep the other element

[SimonHeimberg]

When mounted with --write-overlay, the operations chown my_user d/a_file and chgrp one_of_my_groups d/a_file modify the other element (group when setting user and vice versa) unexpected. chown some_user:some_group d/a_file works as expected.

The other element (group or user) is set to -1 in the file XXX.index.sqlite. Not yet any idea where this value comes from. To get the user on the fs, the value is casted to the biggest allowed user id (which is "nouser" and "nogroup" in my system).

Version: ratarmount 0.15.1, ratarmountcore 0.7.1, ...

[SimonHeimberg]

Version:

$ ratarmount --version
ratarmount 0.15.1
ratarmountcore 0.7.1

System Software:

Python 3.11.2
FUSE 3.14.0
libsqlite3 3.40.1

Compression Backends:

indexed_gzip 1.8.7
indexed_zstd 1.1.3
libarchive 5.1
rapidgzip 0.14.2
rarfile 4.2
xz 0.4.0

Versioned Loaded Shared Libraries:

libzstd-8d126cbb.so.1.5.5
ld-linux-x86-64.so.2
libacl.so.1.1.2301
libarchive.so.13.6.2
libbz2.so.1.0.4
libc.so.6
libcrypto.so.3
libexpat.so.1.8.10
libffi.so.8.1.2
libfuse.so.2.9.9
libgcc_s.so.1
libicudata.so.72.1
libicuuc.so.72.1
liblz4.so.1.9.4
liblzma.so.5.4.1
libm.so.6
libnettle.so.8.6
libpthread.so.0
libsqlite3.so.0.8.6
libssl.so.3
libstdc++.so.6.0.30
libxml2.so.2.9.14
libz.so.1.2.13
libzstd.so.1.5.4

installed today with pipx install ratarmount

[SimonHeimberg]

How to reproduce:

$ ratarmount --write-overlay ~/tmp-s/m-ovl/ ~/tmp-s/m-src1/ ~/tmp-s/mnt/
$ cd ~/tmp-s/mnt/
$ touch a
-rw-r--r-- 1 simon simon 0 22. Jul 22:02 a
$ chown $(id -u) a # "change" owner to myself
$ ls -l a # show strange group
-rw-r--r-- 1 simon nobody 0 22. Jul 22:02 a
$ chown $(id -u) a # repeat, error because can not set group
chown: changing ownership of 'a': Value too large for defined data type
$ sqlite3 -r ../m-ovl/.ratarmount.overlay.sqlite # -1 visible as gid
sqlite> SELECT * FROM files;
path|name|mtime|mode|uid|gid|deleted
|a|1721678521.15942|33188|1000|-1|0
sqlite> .quit
$ chgrp $(id -g) a # set to my (primary) group (any of my groups would be fine)
$ ls -l a # show strange user
-rw-r--r-- 1 nobody simon 0 22. Jul 22:02 a
$ chgrp $(id -g) a # repeat, error because can not set user
chgrp: changing group of 'a': Value too large for defined data type
$ sqlite3 -r ../m-ovl/.ratarmount.overlay.sqlite # -1 visible as uid
sqlite> .head on
sqlite> SELECT * FROM files;
path|name|mtime|mode|uid|gid|deleted
|a|1721678521.15942|33188|-1|1000|0
sqlite> .quit
$ chown $(id -u):$(id -g) # set user and group, works
$ ls -l a # all is fine
-rw-r--r-- 1 simon simon 0 22. Jul 22:02 a
$ cd .. && umount ./mnt/

[mxmlnkn]

Thank you for the detailed bug report! And sorry for the late answer.

The unexpected thing here is that the FUSE callback via fusepy for setting only either the uid or gid, will have the other one set to -1, probably to signal that it is undefined. I did not expect that and simply forwarded that value into the database. Some debug output for the chown $(id -u) a call:

[fusepy.FUSE.chown] uid: 1000, gid: 4294967295
[WritableFolderMountSource.chown] uid: 1000, gid: -1

I'm not sure where the Value too large for defined data type error comes from. In my tests, the FUSE callbacks, not even inside fusepy, are getting called anymore. So it seems that the -1 probably gets converted to some unsigned very large value, which leads to this error. The above debug output does not even get triggered when this error message gets printed.

I have pushed fixes to the develop branch. You can try it out with:

python3 -m pip install --user --force-reinstall 'git+https://github.com/mxmlnkn/ratarmount.git@develop#egginfo=ratarmount'