[PATCH 4/5] virFileRewrite: Allow callback report errors

[Michal Prívozník]

On 2/10/22 17:12, Daniel P. Berrangé wrote:
> On Thu, Feb 10, 2022 at 12:13:25PM +0100, Michal Privoznik wrote:
>> Sometimes it may be handy for the callback to report error, even
>> though our current callbacks are trivial. Let's report an error
>> only if callback returns a well known value, otherwise assume it
>> reported error message on its own.
>>
>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>> ---
>>  src/util/virfile.c | 13 ++++++++++---
>>  1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/util/virfile.c b/src/util/virfile.c
>> index f99e7f95e1..dd065a537c 100644
>> --- a/src/util/virfile.c
>> +++ b/src/util/virfile.c
>> @@ -499,6 +499,10 @@ int virFileUnlock(int fd G_GNUC_UNUSED,
>>   * @uid:@gid (pass -1 for current uid/gid) and written by
>>   * @rewrite callback.
>>   *
>> + * A negative value returned by @rewrite callback is treated as
>> + * error and if the value is different to -1 then it's the
>> + * callback's responsibility to report error.
> 
> I'd sugest just updating the existing caller to always report
> an error, rather than having different semantics for -1 vs -2.
> 
> 
>> @@ -524,9 +529,11 @@ virFileRewrite(const char *path,
>>          goto cleanup;
>>      }
>>  
>> -    if (rewrite(fd, opaque) < 0) {
>> -        virReportSystemError(errno, _("cannot write data to file '%s'"),
>> -                             newfile);
> 
> And simply get rid of this virReportSystemError call entirely


Fair enough, I wanted to not change the signature of the callback,
because the filename is not passed into it. But that's fairly trivial
change.

Michal