Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of michael@metaparadigm.com
 designates 203.117.131.43 as permitted sender)
Message-ID: <475EC19F.8040906@metaparadigm.com>
Date: Wed, 12 Dec 2007 00:58:07 +0800
From: Michael Clark <michael@metaparadigm.com>
Organization: Metaparadigm Pte Ltd
User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009)
MIME-Version: 1.0
To: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
CC: "William A. Rowe, Jr." <wrowe@rowe-clan.net>,
        Iain Wade <iwade@optusnet.com.au>, dev@apr.apache.org
Subject: Re: apr_os_dir_put fixes
References: <d4833ecd0712110524o5be3a386u3c9628dc4e8842b8@mail.gmail.com>
	 <475E944F.3030707@rowe-clan.net>
	 <acf3f2e60712110742r451ffcek3980b14ace05c01f@mail.gmail.com>
	 <475EB4A8.8030409@metaparadigm.com>
 <acf3f2e60712110827pe5142d3g763816d3834e8526@mail.gmail.com>
In-Reply-To: <acf3f2e60712110827pe5142d3g763816d3834e8526@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Lucian Adrian Grijincu wrote:
> 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?
>   

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