History log of /freebsd-10-stable/lib/libc/gen/rewinddir.c
Revision Date Author Comments
# 282979 15-May-2015 julian

MFH: r282485
Tweak seekdir, telldir and readdir so that when htere are deletes going on,
as seek to teh last location saved will still work. This is needed for Samba
to be able to correctly handle delete requests from windows. This does not
completely fix seekdir when deletes are present but fixes the worst of the
problems. The real solution must involve some changes to the API for eh VFS
and getdirentries(2).

Obtained from: Panzura inc
MFH: r282550 (jhb@)
A few style fixes and expand the comment a bit on what _fixtelldir() is
doing.
MFH: r282560 (jhb@)
Tweak the comment here some more. In particular, the previous opening
sentence was a bit confusing.
Noted by: kib


# 271263 08-Sep-2014 jhb

MFC 271048:
Always seek back to the beginning of a regular directory, even if the
previous seek location was 0. Without this, readdir() would see
dd_loc of zero and call getdirentries() which would start reading
entries at the current seek location of the directory ignoring the
first batch of entries. Also, rewinddir() should always seek so that
it reads the directory from the beginning to get updated entries.

PR: 192935
Approved by: re (gjb)


# 270002 14-Aug-2014 jhb

MFC 268531,269079,269204:
Fix various edge cases with rewinddir(), seekdir(), and telldir():
- In the unionfs case, opendir() and fdopendir() read the directory's full
contents and cache it. This cache is not refreshed when rewinddir() is
called, so rewinddir() will not notice updates to a directory. Fix this
by splitting the code to fetch a directory's contents out of
__opendir_common() into a new _filldir() function and call this from
rewinddir() when operating on a unionfs directory.
- If rewinddir() is called on a directory opened with fdopendir() before
any directory entries are fetched, rewinddir() will not adjust the seek
location of the backing file descriptor. If the file descriptor passed
to fdopendir() had a non-zero offset, the rewinddir() will not rewind to
the beginning. Fix this by always seeking back to 0 in rewinddir().
This means the dd_rewind hack can also be removed.
- Add missing locking to rewinddir()
- POSIX says that passing a location returned by telldir() to seekdir()
after an intervening call to rewinddir() is undefined, so reclaim any
pending telldir() cookies in the directory when rewinddir() is called.
- If telldir() is called immediately after a call to seekdir(), POSIX
requires the return value of telldir() to equal the value passed to
seekdir(). The current seekdir code with SINGLEUSE enabled breaks
this case as each call to telldir() allocates a new cookie. Instead,
remove the SINGLEUSE code and change telldir() to look for an existing
cookie for the directory's current location rather than always creating
a new cookie.

PR: 121656


# 282979 15-May-2015 julian

MFH: r282485
Tweak seekdir, telldir and readdir so that when htere are deletes going on,
as seek to teh last location saved will still work. This is needed for Samba
to be able to correctly handle delete requests from windows. This does not
completely fix seekdir when deletes are present but fixes the worst of the
problems. The real solution must involve some changes to the API for eh VFS
and getdirentries(2).

Obtained from: Panzura inc
MFH: r282550 (jhb@)
A few style fixes and expand the comment a bit on what _fixtelldir() is
doing.
MFH: r282560 (jhb@)
Tweak the comment here some more. In particular, the previous opening
sentence was a bit confusing.
Noted by: kib


# 271263 08-Sep-2014 jhb

MFC 271048:
Always seek back to the beginning of a regular directory, even if the
previous seek location was 0. Without this, readdir() would see
dd_loc of zero and call getdirentries() which would start reading
entries at the current seek location of the directory ignoring the
first batch of entries. Also, rewinddir() should always seek so that
it reads the directory from the beginning to get updated entries.

PR: 192935
Approved by: re (gjb)


# 270002 14-Aug-2014 jhb

MFC 268531,269079,269204:
Fix various edge cases with rewinddir(), seekdir(), and telldir():
- In the unionfs case, opendir() and fdopendir() read the directory's full
contents and cache it. This cache is not refreshed when rewinddir() is
called, so rewinddir() will not notice updates to a directory. Fix this
by splitting the code to fetch a directory's contents out of
__opendir_common() into a new _filldir() function and call this from
rewinddir() when operating on a unionfs directory.
- If rewinddir() is called on a directory opened with fdopendir() before
any directory entries are fetched, rewinddir() will not adjust the seek
location of the backing file descriptor. If the file descriptor passed
to fdopendir() had a non-zero offset, the rewinddir() will not rewind to
the beginning. Fix this by always seeking back to 0 in rewinddir().
This means the dd_rewind hack can also be removed.
- Add missing locking to rewinddir()
- POSIX says that passing a location returned by telldir() to seekdir()
after an intervening call to rewinddir() is undefined, so reclaim any
pending telldir() cookies in the directory when rewinddir() is called.
- If telldir() is called immediately after a call to seekdir(), POSIX
requires the return value of telldir() to equal the value passed to
seekdir(). The current seekdir code with SINGLEUSE enabled breaks
this case as each call to telldir() allocates a new cookie. Instead,
remove the SINGLEUSE code and change telldir() to look for an existing
cookie for the directory's current location rather than always creating
a new cookie.

PR: 121656