Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <476B8599.1090608@apache.org>
Date: Fri, 21 Dec 2007 07:21:29 -0200
From: Davi Arnaut <davi@apache.org>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Michael Clark <michael@metaparadigm.com>
CC: dev@apr.apache.org
Subject: Re: [Patch] Proposed Extended Attributes Implementation
References: <4769F773.10503@metaparadigm.com>
 <476B6413.8070201@metaparadigm.com> <476B770C.9010100@apache.org>
 <476B7B23.4020904@metaparadigm.com>
In-Reply-To: <476B7B23.4020904@metaparadigm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael Clark wrote:
> Davi Arnaut wrote:
>> Hi Michael,
>>
>> Michael Clark wrote:
>>   
>>> Michael Clark wrote:
>>>     
>>>> I have been doing some work on implementing extended attributes
>>>> support for apr.
>>>>
>>>> ...
>>>>
>>>> I'll send some initial patches soon. They still need a little work
>>>> and some more test cases.
>>>>       
>>> I've come up with an initial set of patches and a sample client application.
>>>
>>>     
>> [..]
>>
>>   
>>> It may be a week or so before I get time to get a mod_dav_fs_props
>>> implementation that use these interfaces (which i'll post to httpd-dev).
>>> Perhaps also a nice patch for mod_autoindex xattr descriptions.
>>>
>>> Any committers out there who would like to sponsor this?
>>>     
>> From a quick review, it looks good, but I would prefer a apr_file_t
>> based implementation. Other than this, please open a entry on bugzilla
>> so we can track more easily the patches/progress.
>>   
> 
> Thanks. I'll open a bugzilla entry for it.
> 
> Okay, so you recommend a change from const char *filepath to apr_file_t 
> *thefile and fetch the apr_os_file_t (file descriptors) and use the f* 
> variants.

The file descriptor is accessible through apr_file_t::filedes.

> I had used filepath as it seemed consistent with the existing 
> interfaces. i.e. apr_stat, apr_file_perms_set, etc do not have fstat, 
> fchown equivalents.

Hum, we have apr_file_info_get for fstat equivalent. For file
permissions, the path make much more sense..

> I am okay with using file descriptors. Would it be good to have both? 
> e.g. apr_file_xattr_get, apr_file_xattr_get_path

You can access the file name in apr_file_t::fname. Only the apr_file_t
one will suffice.

> Would an apr_file_t based implementation be portable i.e. do you have a 
> call like Solaris' openat on windows that will open the named stream 
> relative to a file handle?

See above, in cases where there is no file descriptor based api, use the
filename in the apr_file_t structure.

Regards,

Davi Arnaut