To: jblunck@suse.de
CC: viro@ftp.linux.org.uk, linux-kernel@vger.kernel.org
In-reply-to: <20051104122021.GA15061@hasse.suse.de> (jblunck@suse.de)
Subject: Re: [RFC,PATCH] libfs dcache_readdir() and dcache_dir_lseek() bugfix
References: <20051104113851.GA4770@hasse.suse.de> <20051104115101.GH7992@ftp.linux.org.uk> <20051104122021.GA15061@hasse.suse.de>
Message-Id: <E1EY16w-0004HC-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Fri, 04 Nov 2005 13:56:02 +0100
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 962
Lines: 23

> > > 
> > > SuSV3 only says: "If a file is removed from or added to the
> > > directory after the most recent call to opendir() or
> > > rewinddir(), whether a subsequent call to readdir_r() returns an
> > > entry for that file is unspecified."
> >  
> > IOW, the applications in question are broken since they rely on
> > unspecified behaviour, not provided by old libc versions.
> 
> No. SuSV3 only says that the behavior of readdir() is unspecified
> w.r.t. an entry for the removed/added file. I think readdir() should
> still return the entries which are not removed/added. What do you
> think?

What 'rm' is this?  Mine (coreutils 5.2.1) doesn't do any seeking and
I don't think that glibc does either.

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/