From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton Altaparmakov Subject: Re: Expected getdents behaviour Date: Thu, 15 Sep 2005 16:17:40 +0100 Message-ID: <1126797460.1676.23.camel@imp.csi.cam.ac.uk> References: <1126793268.1676.9.camel@imp.csi.cam.ac.uk> <1126793558.1676.15.camel@imp.csi.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: aaranya@cs.sunysb.edu, linux-fsdevel@vger.kernel.org Return-path: Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]:11240 "EHLO ppsw-0.csi.cam.ac.uk") by vger.kernel.org with ESMTP id S1030492AbVIOPR4 (ORCPT ); Thu, 15 Sep 2005 11:17:56 -0400 To: Miklos Szeredi In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2005-09-15 at 16:45 +0200, Miklos Szeredi wrote: > > 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... > > Why is it crap? 'rm -rf' does exactly the same. Then that is broken, too. But have you ever looked? I just did and you are partially wrong. It especially handles the case correctly by doing a "rewinddir()" on the directory before doing another readdir() after it has done an unlike. However you are right in that it only enables this code at ./configure time so on most Linux systems will not have it enabled in which case it will indeed be broken on filesystems like ntfs. > It's up to the filesystem to keep track of the file position in the > directory, regardless of any deletions or additions. That is completely untrue. It is up to the user. The file position in a directory is completely up to the caller and in particular when a directory is modified the file position in that directory is not changed by the filesystem. Doing this would in fact be impossible since the creation/deletion in the kernel has no access to all the "struct file"s with which a directory has been opened. 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/