NFS/Emacs bug

NFS/Emacs bug

[Per Abrahamsen]

When using `directory-files' on large directories (5000+ files) the
answer is sometimes truncated, like this:

	(length (directory-files "~/Mail/ding/list"))
	==> 2287
	(length (directory-files "~/Mail/ding/list"))
	==> 5460

This has been reproduced with Linux and Solaris as NFS clients and
with SGI and Solaris as NFS servers.  It has also been reproduced with
Emacs 19.30, Emacs 19.31, and XEmacs 19.13.

The problem is noticeable when using the `nnml' backend for Gnus to
store large groups.

I cannot produce similar result from the shell, e.g. with:

	% ls -1 ~/Mail/ding/list | wc -w
	5456

Re: NFS/Emacs bug

[Eli Zaretskii]

On 3 Jun 1996, Per Abrahamsen wrote:

> When using `directory-files' on large directories (5000+ files) the
> answer is sometimes truncated, like this:
> 
> 	(length (directory-files "~/Mail/ding/list"))
> 	==> 2287
> 	(length (directory-files "~/Mail/ding/list"))
> 	==> 5460
> 
> This has been reproduced with Linux and Solaris as NFS clients and
> with SGI and Solaris as NFS servers.  It has also been reproduced with
> Emacs 19.30, Emacs 19.31, and XEmacs 19.13.

`directory-files' (on dired.c) tests the directory entries returned by 
`readdir' to be non-empty, by using the `DIRENTRY_NONEMPTY' macro.  That 
macro looks at the inode returned in dp->d_ino, and if it's zero, the 
entry is considered empty.  I suggest stepping through the loop that 
calls `readdir' with a debugger to see whether maybe under that specific 
combination of NFS servers and clients, the inode is sometimes reported 
as 0 when it shouldn't have been.