lkml.org 
[lkml]   [2005]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-11-04 14:21    [W:0.224 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site