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 [email protected] [email protected] [email protected] PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
