Lucian Adrian Grijincu wrote:
On Dec 11, 2007 6:02 PM, Michael Clark <[EMAIL PROTECTED]> 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
