[Top][All Lists]

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

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

From: Alfred M. Szmidt
Subject: Re: weird ls behaviour on GNU/Hurd...
Date: Wed, 17 Mar 2004 13:24:05 +0100 (MET)

   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.

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.

reply via email to

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