This looks like an LFS problem in tcsh, I just tried the same thing
here and got the same result:
[root@lord test]# ls -l
total 40
-rw-r--r-- 1 root root 17216640383 Apr 24 10:54 file-0
-rw-r--r-- 1 root root 15070071336 Apr 24 10:54 file-1
-rw-r--r-- 1 root root 4347143726 Apr 24 10:54 file-2
-rw-r--r-- 1 root root 10759544014 Apr 24 10:54 file-3
-rw-r--r-- 1 root root 4304621114 Apr 24 10:54 file-4
-rw-r--r-- 1 root root 15096636685 Apr 24 10:54 file-5
-rw-r--r-- 1 root root 4301995631 Apr 24 10:54 file-6
-rw-r--r-- 1 root root 8620495032 Apr 24 10:54 file-7
-rw-r--r-- 1 root root 2201270380 Apr 24 10:54 file-8
-rw-r--r-- 1 root root 8641931080 Apr 24 10:54 file-9
[root@lord test]# bash
[root@lord test]# echo *
file-0 file-1 file-2 file-3 file-4 file-5 file-6 file-7 file-8 file-9
[root@lord test]#
[root@lord test]# tcsh
[lord@lord test]# echo *
echo: No match.
[lord@lord test]#
This probably has more to do with the code in tcsh than anything else, there
are calls in the kernel which report 64 bit sizes, it is up to user apps to
use the correct calls. I was able to rebuild tcsh with -D_FILE_OFFSET_BITS=64
and make the problem go away, but I suspect it really needs some help
in the tcsh source.
I found another example in the stat binary which is odd:
[root@lord test]# stat file-9
file-9: Value too large for defined data type
but running strace -v on it:
lstat64("file-9", {st_dev=makedev(8, 5), st_ino=4238314, st_mode=S_IFREG|0644,
st_nlink=1, st_uid=0, st_gid=0, st_blksize=8192, st_blocks=8,
st_size=8641931080, st_atime=2001/04/24-10:54:33, st_mtime=2001/04/24-10:54:33,
st_ctime=2001/04/24-10:54:33}) = 0
There is the 8G file being returned from the lstat64 call.
Steve
p.s. on a side note, the pre-release kernel you are running is rather old now.
> Hi.
>
> I'm sorry to bother you personally, but I have been having problems
> subscribing to the XFS-linux port mailing list. Reading through the
> archives (trying to see if anyone else has had the same problems as I
> have) I noticed your name/email and that you had answered a number of
> technical questions, so I hope you can help me.
>
> We've been running XFS (used the SGI XFS Pre-release 0.9) for about a
> month. No problems, except some bizarre behaviour.:
>
> > ls
> file1.MYD file2.MYD file3.MYD file4.MYD
>
> > ls *.MYD
> file4.MYD
>
> I changed to the bash shell (tcsh) and everything was fine. All the
> files are larger than 2GB, with the exception of file4.MYD. So looking
> through the globbing code of tcsh, I noticed that it was doing a
> stat(). I ran stat on the files larger than 2GB and stat returned the
> following error : Value too large for defined data type. (I am assuming
> that it is referring to the off_t).
>
> I am worried about this behaviour and if it will affect other programs
> that use stat(). Your help illuminating what is going on would be
> greatly appreciated.
>
> Btw, we are running the 2.4.0-SGI_XFS_PR kernel (recompiled for a couple
> of things).
>
>
> Once again, I apologize for not going through the mailing list, and
> bothering you.
>
> Thanks
>
> B.
|