On Sun, Nov 13, 2005 at 09:45:14PM +0100, Michael van Elst wrote:
> readdir() itself doesn't call llseek, but it calls a wrapper around
> the syscall getdents/getdents64.
> 
> That wrapper tries to translate between kernel dirent structure and
> glibc dirent structure. There is no translation when the structures
> "look" compatible. Normally the wrapper calls getdents64() unless
> there is no such syscall or getdents64() returned ENOSYS.
> 
> 
> When calling getdents64() it checks for overflowing d_ino and d_off
> fields. This can happen when the calling program is compiled for
> 32bit file offsets and d_ino larger than 32bit or d_off larger than
> 31bit.
> 
> When there is an overflow and there is at least one good entry
> it llseeks() back to the previous d_off value, the next iteration
> will reread the untranslatable entry and abort with EOVERFLOW.
> 
> When d_off is not a valid offset, the llseek fails and the next
> iteration may or may not read more directory entries.

How can d_off be invalid? It was returned by the kernel before, so it
should be valid, no?

Pavel Cahyna