On 10 January 2012 09:16, Jim Meyering <j...@meyering.net> 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
