This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: readdir.c: d_off instead of d_reclen [PATCH]


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 */

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.

Cheers,
Shaun

On 6/3/05, Jeff Johnston <jjohnstn@redhat.com> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]