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. > Thanks! > > cheers, josch cu Adrian BTW: e2fsprogs added AC_USE_SYSTEM_EXTENSIONS 10 years ago, therefore manual #define _GNU_SOURCE 1 could also be removed.