On Mon, Jan 28, 2002 at 12:24:12PM -0600, Karl Fogel wrote:
> Therefore, not only is the comment wrong, but the APR_FINFO_MIN flag
> is wrong. Don't we want APR_FINFO_PROT instead? Here are their
> definitions in apr_file_info.h:
>
> #define APR_FINFO_MIN 0x00008170 /**< type, mtime, ctime, atime, size */
> #define APR_FINFO_PROT 0x00700000 /**< all protections */
>
> Am I missing something here?
protection seems to be filled out on all platforms from what I can
tell (wouldn't be if we specified APR_FINFO_NAME on Win32). But, if
you only want the permissions, IMHO, the safe thing to do is to just
specify APR_FINFO_PROT. But, as the code stands right now, APR will
pretty much give you everything.
> Maybe apr_copy_file() and its helper should take a flag that indicates
> either the perms to use for the new file, or to use the same perms as
> the old file (we could add a new flag value for that if necessary).
>
> How does that sound? Any thoughts from APR people?
How about apr_copy_file takes in the perms of the new file? Perhaps
a special value to indicate to use the umask or even the old perms?
I think we use this "special value" construct other places. (Ah,
apr_temp_file_create, IIRC...)
> > What is the status of these "apr in subversion" functions?
>
> I think these functions were meant to go into APR eventually, I'm not
> sure why they haven't yet. If there's currently a bug, obviously that
> would be one reason not to put them in APR yet. :-)
Code style for one. =) But, I see no overall reason why it
couldn't go into APR.
It'd also need to be renamed to apr_file_copy() not apr_copy_file()
to follow APR's naming conventions. Perhaps someone can clean it
up and post a suitable patch to dev@apr? I have no idea when I'd
be able to get to it... -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:01 2006