From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton Altaparmakov Subject: Re: Expected getdents behaviour Date: Thu, 15 Sep 2005 22:17:12 +0100 (BST) Message-ID: References: <1126793268.1676.9.camel@imp.csi.cam.ac.uk> <1126793558.1676.15.camel@imp.csi.cam.ac.uk> <1126797460.1676.23.camel@imp.csi.cam.ac.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: aaranya@cs.sunysb.edu, linux-fsdevel@vger.kernel.org Return-path: Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]:24543 "EHLO ppsw-1.csi.cam.ac.uk") by vger.kernel.org with ESMTP id S1030515AbVIOVRT (ORCPT ); Thu, 15 Sep 2005 17:17:19 -0400 To: Miklos Szeredi In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 15 Sep 2005, Miklos Szeredi wrote: > > 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. > > And does not need to. The only thing the filesystem must do is to > guarantee, that IF the file position wasn't changed since the last > getdents() call (i.e. no lseek(), or zero relative offset lseek() was > done), the directory reading should continue from the place where it > has been left off. But how do you define "the place where it has been left off"? What you are saying is hand waving. No actual meaning behind those words. Example: f_pos = logical byte offset inside the linear on-disk directory stream. (This is what ntfs uses.) So if you do not change f_pos, the next readdir() will continue at the same logical byte offset inside the linear on-disk directory stream, i.e. it will continue at "the place where it has been left off". Which is what you specified! Notice the problem? There is no guarantee whatsoever that after a rm or create, this offset inside the on-disk directory stream points to the same directory entry any more since the entries will have been moved around. Even worse the very entry it was pointing to may have been removed altogether so its place will have been filled by a different entry. > Look at dcache_readdir() in fs/libfs.c for a way to deal with exactly > this problem. AFAICS this only works because it is a linked list. But I am rather tired now so I may well be missing something. That function is not very easy to understand... 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/