Re: [PATCH 3/5] write_file(): introduce an explicit WRITE_FILE_GENTLY request

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

 



On Tue, Aug 25, 2015 at 1:41 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> All callers except for two ask this function to die upon error by
>> passing fatal=1; turn the parameter to a more generic "unsigned flag"
>> bag of bits, introduce an explicit WRITE_FILE_GENTLY bit and change
>> these two callers to pass that bit.
>
> There is a huge iffyness around one of these two oddball callers.
>
>> diff --git a/setup.c b/setup.c
>> index 5f9f07d..718f4e1 100644
>> --- a/setup.c
>> +++ b/setup.c
>> @@ -404,7 +404,7 @@ static void update_linked_gitdir(const char *gitfile, const char *gitdir)
>>
>>       strbuf_addf(&path, "%s/gitfile", gitdir);
>>       if (stat(path.buf, &st) || st.st_mtime + 24 * 3600 < time(NULL))
>> -             write_file(path.buf, 0, "%s\n", gitfile);
>> +             write_file(path.buf, WRITE_FILE_GENTLY, "%s\n", gitfile);
>>       strbuf_release(&path);
>>  }
>
> This comes from 23af91d1 (prune: strategies for linked checkouts,
> 2014-11-30).  I cannot tell what the justification is to treat a
> failure to write a gitfile as a non-error event.  Just a sloppy
> coding that lets the program go through to its finish, ignoring the
> harm done by possibly corrupting user repository silently?

Failing to write to this file is not a big deal _if_ the file is not
corrupted because of this write operation. But we should not be so
silent about this. If the file content is corrupted and it's old
enough, this checkout may be pruned. I think there's another bug
here... wrong name..
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]