Messages in this thread | | | Date | Fri, 4 Nov 2005 14:18:58 +0100 | From | jblunck@suse ... | Subject | Re: [RFC,PATCH] libfs dcache_readdir() and dcache_dir_lseek() bugfix |
| |
On Fri, Nov 04, Miklos Szeredi wrote:
> > > > > > > > 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. >
As I said: "Old glibc implementations (e.g. glibc-2.2.5) are lseeking after every call to getdents() ..."
Precisely this is a SLES8 on s390-64bit. s390vm02:/# rpm -qf /bin/rm fileutils-4.1.11-144 s390vm02:/# rpm -q glibc glibc-2.2.5-234
But you can also try my testcase.
Regards, Jan Blunck
-- Jan Blunck jblunck@suse.de SuSE LINUX AG - A Novell company Maxfeldstr. 5 +49-911-74053-608 D-90409 Nürnberg http://www.suse.de - 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/
| |