From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton Altaparmakov Subject: Re: Expected getdents behaviour Date: Thu, 15 Sep 2005 15:12:38 +0100 Message-ID: <1126793558.1676.15.camel@imp.csi.cam.ac.uk> References: <1126793268.1676.9.camel@imp.csi.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]:20707 "EHLO ppsw-0.csi.cam.ac.uk") by vger.kernel.org with ESMTP id S965159AbVIOOMr (ORCPT ); Thu, 15 Sep 2005 10:12:47 -0400 To: Akshat Aranya In-Reply-To: <1126793268.1676.9.camel@imp.csi.cam.ac.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2005-09-15 at 15:07 +0100, Anton Altaparmakov wrote: > On Thu, 2005-09-15 at 09:57 -0400, Akshat Aranya wrote: > > I noticed that bonnie++, in its directory tests, does the following on > > a large directory > > > > open(dir); > > while (getdents() != 0) > > { > > unlink all the returned entries from getdents > > } > > close(dir); > > > > My question is whether the filesystem's readdir is expected to > > consider the offset value in the second readdir to still be valid, > > given that entries from the directory were deleted after the first > > readdir. > > This would fail horribly on ntfs for example (once it supports file > deletion anyway) since the offset value of all entries changes when the > directory is modified. Oops. I forgot to answer your question. Yes, the filesystem needs to consider the offset value in the second readdir to still be valid. You cannot keep rewinding back to zero every time you make a modification or you would keep returning entries you have already returned and never make any progress if e.g. some user does this in a loop at the same time: while 1; do touch blah rm blah done It would be a very effective DOS that any user can trigger. Bonnie++'s code is just complete crap... It is the author's fault that it will not work on filesystems where the directory entries are not in fixed locations... Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/