[bug #65578] Numeric user ID too large when generating the tarball

[Giacomo Lorenzetti]

Follow-up Comment #3, bug #65578 (group gnuastro):

Thanks Mohammad.

Unfortunately the "fastest solution" won't work either: on gnutar -o is also
an alias for --old-archive, that is '--format=v7'. Incidentally, this also
mean that we aren't using the same format, apparently.
Here is branch that forces the same format (ustar, as per convo in Maneage),
regardless of the tar used:
https://gitlab.cefca.es/glorenzetti/gnuastro/-/commit/b9f950d79fa1a64468b99f9b9be770461c5c702e
(Note: this doesn't fix Raul's issue, it's just for homogeneous reasons)

Speaking of the issue, let me stress what triggered it: the output of 'id -u'
and 'id -g' on Raul's computer is O(10⁹), while on a typical Linux the
result is O(10³) (usually both start from 1000, adding +1 for a new user,
unless different settings). Testing on personal MacOSes, the result is ~500.
To have userIDs that big is strange, and even the comment in the autogenerated
aclocal.m4 is along the same lines:
>     [# The POSIX 1988 'ustar' format is defined with fixed-size fields.
>      # There is notably a 21 bits limit for the UID and the GID.  In fact,
>      # the 'pax' utility can hang on bigger UID/GID (see automake bug#8343
>      # and bug#13588).
>      am_max_uid=2097151 # 2^21 - 1
>      am_max_gid=$am_max_uid
>      # The $UID and $GID variables are not portable, so we need to resort
>      # to the POSIX-mandated id(1) utility.  Errors in the 'id' calls
>      # below are definitely unexpected, so allow the users to see them
>      # (that is, avoid stderr redirection).
I'm investigating why those numbers are that big.

Rearding the usage of userIDs in the metadata, the idea is interesting and
will probably solve also the issue (I guess that tar wouldn't crash if it
avoids reading IDs...). The issue is then how to put those in automake, I'm
looking into it.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65578>

_______________________________________________
Mensaje enviado vía Savannah
https://savannah.gnu.org/