readdir.c: d_off instead of d_reclen [PATCH]

Fri Jun 3 21:45:00 GMT 2005

On Fri, 3 Jun 2005, Shaun Jackman wrote:

> Hello Jeff,
> Thanks for the informative dirent(4) man page. My system (Debian
> Sarge) doesn't have a dirent man page, and so I was going by this
> cryptic line from getdents(2):
>                   off_t d_off;                /* offset to next dirent */

I believe that it can be arbitrary.  On Linux, it is documented to be the 
offset to the next entry, but on HPUX which IIRC is where I found that 
other man page it is the offset to the current entry.
> The system I'm using is an in-house ARM kernel that implements the ARM
> RDP syscall interface with some extensions. It interleaves struct
> dirent and struct stat on disk, so d_reclen indicates the length of
> the current struct dirent, and d_off is a relative offset past both
> the struct dirent and the struct stat to the next struct dirent on
> disk.
> Do you have any thoughts on why Linux seems to massage the data coming
> off the disk before it returns the data through getdents? The d_off
> fields do not reflect the location of the records in the data returned
> by getdents.

Remember that the d_off field is the offset of the next dirent from 
"the start of the directory".  It doesn't infer from the start of the 
output returned by getdents if that is how you have interpreted it.

-- Jeff J.

> Shaun
> On 6/3/05, Jeff Johnston <> wrote:
> > Shaun,
> > 
> >    The d_off field is not an offset to the next entry from the current entry; it
> > is instead from the start of the directory: "d_off is the distance from the
> > start of the directory to the start of the next dirent."  I have seen a
> > different definition of this field being the current directory entry as
> > illustrated below:
> > 
> >    Is there a problem you are solving with this change whereby the d_reclen
> > field calculation did not give you a correct entry and if so, what system?
> > 
> > -- Jeff J.

More information about the Newlib mailing list