I can't reproduce it on my GNU/Linux x86 box.
Okie.
Here's the code that generates that number, in src/ls.c line 3109:
sprintf (p, "%s %*s ", modebuf, nlink_width,
umaxtostr (f->stat.st_nlink, hbuf));
If you can reproduce the problem, can you please use GDB to plant a
breakpoint just before the sprintf and see what the value of
f->stat.st_nlink is? Possibly it's some sort of mismatch between
the C headers and the kernel or filesystem, such that ls thinks
that st_nlink is 32 bits even though it's really 16 bits. Another
possibility is that incorrect machine code is being used to widen
from f->stat.st_nlink to unitmax_t; you can tell whether this is
true by disassembling print_long_format.
Will do when I get some spare time, which might be today actually...
Another possibility is to use strace to see what the result of
statting that file actually reported to "ls".
GNU/Hurd doesn't have strace.
Thanks for the ideas and tips.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
