I have now reported this upstream since I consider this to be a bug in
the FreeBSD Linux compat layer:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277804
I did some more investigation with stat(2). Running native on FreeBSD
with Python os package 'st_dev':
$ df -t ufs | cut -f 6 -w | sed 1d | xargs -I% python ~/stat.py %
/: 108
/tmp: 110
/var: 111
/var/tmp: 112
/usr: 113
/usr/local: 161
/usr/ports: 142
/usr/obj: 141
/usr/local/pgsql: 140
/var/ne
Disclaimer: I am not 100% certain whether this is a bug in GNU coreutils
or FreeBSD Linux emulation layer because the behavior is weird. So,
please bear with me.
Consider the following output on FreeBSD 13 from FreeBSD's df(1):
$ df -t ufs -b -T -a
Filesystem Type 512-blocks U
On 2023-08-21 21:25, Paul Eggert wrote:
On 8/21/23 05:51, Osipov, Michael (IN IT IN) via GNU coreutils Bug
Reports wrote:
in 9.3 year 2038 support with 64 bit time_t was made required [1],
here on HP-UX this is a bit problematic, but that's not the actual
problem. The diff between 9.2 an
Folks,
in 9.3 year 2038 support with 64 bit time_t was made required [1], here
on HP-UX this is a bit problematic, but that's not the actual problem.
The diff between 9.2 and 9.3 [2] says how this can be fixed on platforms
supporting both 32 and 64 bit, on HP-UX it'd be simply '+DD64', and how
