Lucian Adrian Grijincu wrote: > On Dec 11, 2007 6:02 PM, Michael Clark wrote: > >> Lucian Adrian Grijincu wrote: >> >>> apart from the versioning detail, Iain raises a valid problem (bug) in APR: >>> >> Yes, although even with the allocation fixed, without dirname set >> correctly, it will also not be able to do the apr_stat calls if they are >> 'wanted' in apr_dir_read. >> >> > > A few things can still be found without changing the interface. > struct dirent { > ino_t d_ino; /* inode number */ > off_t d_off; /* offset to the next dirent */ > unsigned short d_reclen; /* length of this record */ > unsigned char d_type; /* type of file */ > char d_name[256]; /* filename */ > }; > > The ino, type and name of the file can still be found, but not more. > so, if you only need APR_FINFO_NAME|APR_FINFO_INODE|DIRENT_TYPE or > less, you could go from here. > Also, if you have the dirname to begin with, you can concatenate that > with the .name member set up by apr_dir_read in apr_finfo_t and do it > manually. > Or am I missing something? > A use case example is making some existing code that reads from an apr_dir_t work with an apr_dir_t that has been created using apr_os_dir_put. Some code (e.g. mod_autoindex) is minimally changed to call a portable interface that normally just dispatches to apr_dir_open. When a privilege seperation feature is enabled, it instead delegates to a routine that requests the directory file descriptors be sent over a socket (or potentially a file handle over a memory file on windows). By being able to set the dirname, have the apr_dir_t properly allocated, this existing code can be changed minimally (a couple of 1 line changes). With the limitations mentioned above, it would need to be changed in a much more complicated way - ie. changing the wanted mask, adding extra apr_stat calls, changing the dir_close call (for cleanup to work), etc