apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucian Adrian Grijincu" <lucian.griji...@gmail.com>
Subject Re: apr_os_dir_put fixes
Date Tue, 11 Dec 2007 16:27:22 GMT
On Dec 11, 2007 6:02 PM, Michael Clark <michael@metaparadigm.com> 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?

> So the 'bug' can't really be fixed without changing the interface or
> adding an apr_dir_set_dirname(d, dirname)
>
> I don't think it is a very useful interface - should it be deprecated
> perhaps?
>
> We have some code that uses the existing interface but it needs to
> include arch/unix/apr_arch_file_io.h to access the dirname member to do
> the fixups.
>

Either that or add some new functionality to route around the problem.
a function like apr_dir_set_dirname, or making part of the apr_dir_t
public and some of this an *impl pointer.
I'd favor a better _ex() variant though.


-- 
Lucian

Mime
View raw message