From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/6509 Path: main.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.gnus.general Subject: Re: NFS/Emacs bug Date: Tue, 4 Jun 1996 13:14:33 +0200 (IST) Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1035146953 3847 80.91.224.250 (20 Oct 2002 20:49:13 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:49:13 +0000 (UTC) Cc: xemacs@cs.uiuc.edu, bug-gnu-emacs@prep.ai.mit.edu, ding@ifi.uio.no Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.5/8.6.9) with SMTP id EAA08014 for ; Tue, 4 Jun 1996 04:58:01 -0700 Original-Received: from is.elta.co.il (is.elta.co.il [199.203.121.2]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 4 Jun 1996 13:18:46 +0200 Original-Received: by is.elta.co.il (5.x/SMI-SVR4) id AA24088; Tue, 4 Jun 1996 13:14:34 +0200 X-Sender: eliz@is Original-To: Per Abrahamsen In-Reply-To: Xref: main.gmane.org gmane.emacs.gnus.general:6509 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:6509 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.