Re: UFS dirent d_reclen

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I'm having trouble understanding the value of d_reclen for a dirent
> returne to me by readdir(2).  For example:

> mkdir dir
> touch dir/f

> If I now opendir(2) 'dir' and ask it to print info
> about the dirents [...] I get [all d_reclens are 16]

> Inspection of the directory itself via hexdump [...]  So I'd have
> expected dirp->d_reclen to give me '12', '12', and '488', instead of
> '16', '16', '16'.

> What am I getting wrong here?

You're expecting readdir()'s return values to be too similar to the
on-disk format.  readdir() returns the same struct regardless of
whether you're reading an FFS directory, an MSDOSfs directory, an NTFS
directory, an NFS directory, etc.  The similarity of readdir()'s return
struct to the FFS on-disk format is...well, I'd call it a historical
artifact, a holdover from the days when reading directories _did_
basically return what was stored on disk.

I also conjecture that you're on a 64-bit architecture, on which struct
dirent is padded as necessary for 8-byte alignment[%], so all d_reclen
values will be multiples of 8, which semi-compels massaging of the data
somewhere between the on-disk format and readdir(2)'s format.  My
impression is that this happens mostly inside the kernel; see
getdents(2), or whatever the underlying syscall is called these days if
that name is out of date - as of what I have here, that too returns,
loosely speaking, structs dirent.

[%] This might be an unwarranted inference.  Depending on things I am
    not in a position to check right now, struct dirent might be
    getting aligned to 8-byte alignment even on some/all 32-bit ports.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B