Re: Bug: .gitconfig folder

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

 



On Wed, May 27, 2015 at 3:18 PM, Jeff King <peff@xxxxxxxx> wrote:
> On Wed, May 27, 2015 at 01:30:29PM -0700, Junio C Hamano wrote:
>
>> Jorge <griffin@xxxxxx> writes:
>>
>> > If you have a folder named ~/.gitconfig instead of a file with that
>> > name, when you try to run some global config editing command it will
>> > fail with a wrong error message:
>> >
>> >     "fatal: Out of memory? mmap failed: No such device"
>>
>> That indeed is a funny error message.
>>
>> How about this patch?
>>
>> -- >8 --
>> We show that message with die_errno(), but the OS is ought to know
>> why mmap(2) failed much better than we do.  There is no reason for
>> us to say "Out of memory?" here.
>>
>> Note that mmap(2) fails with ENODEV when the file you specify is not
>> something that can be mmap'ed, so you still need to know that "No
>> such device" can include cases like having a directory when a
>> regular file is expected, but we can expect that a user who creates
>> a directory to a location where a regular file is expected to be
>> would know what s/he is doing, hopefully ;-)
>>
>>  sha1_file.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/sha1_file.c b/sha1_file.c
>> index ccc6dac..551a9e9 100644
>> --- a/sha1_file.c
>> +++ b/sha1_file.c
>> @@ -720,7 +720,7 @@ void *xmmap(void *start, size_t length,
>>               release_pack_memory(length);
>>               ret = mmap(start, length, prot, flags, fd, offset);
>>               if (ret == MAP_FAILED)
>> -                     die_errno("Out of memory? mmap failed");
>> +                     die_errno("mmap failed");
>>       }
>
> This is definitely an improvement, but the real failing of that error
> message is that it does not tell us that "~/.gitconfig" is the culprit.
> I don't think we can do much from xmmap, though; it does not have the
> filename. It would be nice if we got EISDIR from open() in the first
> place, but I don't think we can implement that efficiently (if we added
> an "xopen" that checked that, it would have to stat() every file we
> opened).

What is our thinking for after-fact recovery attempts?
Like we try the mmap first, if that fails we just use open to get the
contents of
the file. And when open fails, we can still print a nice error message?

>
> -Peff
> --
> 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
--
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]