ls -l reports: /hdc2/tools/2002/shell/bin/ls: : No such file or directory /hdc2/tools/2002/shell/bin/ls: : No such file or directory /hdc2/tools/2002/shell/bin/ls: : No such file or directory ie each name has a NUL byte at the front
gdb shows field sizes: ls glibc struct dirent dirent64 d_ino 8 8 d_off 4 8 d_reclen 2 2 d_type 1 1 d_name ... ... Breakpoint: ls.c line 1763 print_dir readdir.c line 42 __READDIR d_name is offset by 4 and usually picks up a NUL byte at the start. I can guess that this is an installation issue, picking up the wrong header, or the wrong #define, but I cant find where. The background system is mandrake 7.2, but it SHOULD be picking up new things all round, with a local prefix: glibc-2.2.5 (not libc-2.1.3) fileutils-4.1 gcc-3.3 (CVS) linux-2.4.19 cpu-i586 AMD fileutils was compiled last, glibc was built with gcc-3.2 which built 3.3, and /usr/include/linux does-> /usr/src/linux/include/linux. ldd and type shows that the new prefixes are being used, though they do have their own different prefixes: /tools/2002/glibc /tools/2002/shell I have the output from configure and build, if that helps. The scripts I use (21K) to build with are: (a moving target) http://homepage.ntlworld.com/information-cascade/baks/ 2002_go.tar.gz gdb (insight-cvs) seems to be capable of resolving the different dirent topologies, do you want me to run some utility to see what was? I realise that my setup is confusing, but how did fileutils get the wrong header, or modifiers? regards -- Graham [EMAIL PROTECTED] PS: I saw recently that RedHat are staggering their releases, so that (Oracle-etc) dont fall between two levels. My experience is that libc-2.2.5 wont load things from 2.1.3 _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils