[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Reuben Thomas
Subject: Re: copy_file_preserving variant that doesn't exit on error?
Date: Tue, 10 Jan 2012 18:35:36 +0000

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,

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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]