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
