[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: weird ls behaviour on GNU/Hurd...

From: Paul Eggert
Subject: Re: weird ls behaviour on GNU/Hurd...
Date: 16 Mar 2004 16:39:29 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

"Alfred M. Szmidt" <ams@kemisten.nu> writes:

> Well, if any GNU/Linux users can reproduce it please report it.  The
> easy way is to list all files in a directory (it should contain lots
> of files, the more the better) using the long listing option for ls
> (-l).

I can't reproduce it on my GNU/Linux x86 box.

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.

Another possibility is to use strace to see what the result of
statting that file actually reported to "ls".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]