On Tue, Apr 30, 2024 at 09:45:27AM +0300, Adrian Bunk wrote:
> On Mon, Apr 29, 2024 at 11:12:54AM +0200, Johannes Schauer Marin Rodrigues wrote:
> >...
> > I attached a minimal reproducer. It includes an embedded gzipped tarball with a
> > single file called "myfilename" of size 10. It works fine if _FILE_OFFSET_BITS
> > is not set but with it, it reports a wrong archive member size of zero on
> > mips64el:
> >...
> > st_uid = 1000, st_gid = 1000, st_rdev = 0, st_pad2 = {0, 0, 10}, st_size = 0,
> >...
> > As one can see, the size "10" is not in st_size but in the padding before the
> > st_size member. This only happens when _FILE_OFFSET_BITS=64 and only on
> > mips64el.
> >
> > Any idea what is going on with mips64el?
>
> The assumption that _FILE_OFFSET_BITS=64 would be a NOP on 64-bit is
> not true on MIPS, where stat and stat64 differ in padding and
> _FILE_OFFSET_BITS=64 switches stat to the stat64 padding:
> https://sources.debian.org/src/glibc/2.36-9%2Bdeb12u4/sysdeps/unix/sysv/linux/mips/bits/struct_stat.h/#L149-L156
>
> AC_SYS_LARGEFILE was added to e2fsprogs configure.ac 2 years ago,
> therefore manual
> #define _FILE_OFFSET_BITS 64
> #define _LARGEFILE64_SOURCE 1
> should no longer be necessary for architectures where it is needed.
Yeah, I think that's what Helmut Grohne said in #1068251, I knew I had
seen it before. So IMHO the problem here is indeed not in libarchive, but,
yes, in e2fsprogs setting FILE_OFFSET_BITS=64 unconditionally.
As such, if no one objects, I think this bug should be closed and
e2fsprogs should indeed rely on AC_SYS_LARGEFILE (as libarchive already does)
instead.
Thanks everyone for tracking this down!
G'luck,
Peter
--
Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Attachment:
signature.asc
Description: PGP signature