Re: copy_file_preserving variant that doesn't exit on error?

[Reuben Thomas]

On 10 January 2012 09:16, Jim Meyering <address@hidden> wrote:
> A couple of suggestions:

Thanks for the review.

>  ERR_READ may be too generic, risking collision with symbols defined by
>  other applications.  Perhaps names like GL_COPY_READ_FAILURE,
>  GL_ACL_PRESERVE_FAILURE, etc.

I now have GL_COPY_ERR_*. Is that OK, or would you prefer something else?

> Regarding the tests, it'd be nice if your added test code
> could exercise a few of the newly-exposed error return values.

I'm working on this. However, there seems to be a misapprehension
here: if you look at my patch, you'll see that currently the new error
codes are only used internally, to vary the output of
copy_file_preserving in the case of error. copy_file_preserving_error
(and you never said: is that an OK name? It seems not quite right to
me as it implies that it is "preserving the error", whatever that
means) returns either 0 or -1. Are you saying I should expose the
error codes externally?

> One more thing, I noticed that your ERR_ACL case does not
> print anything.  I suppose that is just to remain completely
> compatible with existing code?  It seems like it'd be better
> to diagnose that failure, too.

I've added an error message to this case.

Thanks again for your guidance!

-- 
http://rrt.sc3d.org