Re: [PATCH] unpack-trees.c: check return value of lstat()

["Torsten Bögershausen" <tboegi@web.de>]

On 06.03.11 21:57, Matthieu Moy wrote:
> Torsten Bögershausen <tboegi@web.de> writes:
> 
>> On 06.03.11 20:29, Matthieu Moy wrote:
>>> Torsten Bögershausen <tboegi@web.de> writes:
>>>
>>>> +		if (!lstat(path, &st))
>>>> +			return check_ok_to_remove(path, len, DT_UNKNOWN, NULL, &st,
>>>> +			                          error_type, o);
>>>>  	} else if (!lstat(ce->name, &st))
>>>
>>> What happens if lstat returns a non-0 value?
>> The result of "st" is 100% garbage, and should not be passed to
>> anybody.
> 
> With your code, you don't do a return, you'll reach the end of the
> function without calling return, which is probably the worst thing you
> could expect.
> 
>> v1.7.4 says:
>> commit e39212ab08e8d37dda5d8fd32b54099fe01dbbdb
>> Merge: 716958c 9e08273
> 
> You've cut the date:
> 
> commit e39212ab08e8d37dda5d8fd32b54099fe01dbbdb
> Merge: 716958c 9e08273
> Author: Junio C Hamano <gitster@pobox.com>
> Date:   Wed Dec 22 14:40:26 2010 -0800
> 
> => no big surprise that you don't see the bugfix from Jan 12th.
> 
>>> Anyway, this seems to have been fixed by a93e53018 (Wed Jan 12 20:28:09
>>> 2011, unpack-trees: handle lstat failure for existing file) already.
> 
> Did you look at the content of this commit?
> 
>> (And I had to correct drizzd@aon.a -> drizzd@aon.at)
> 
> Yes, because you've mis-spelled it in the first place and I didn't fix
> it ;-).
> 

Ojojo,
While working with the best tracking tool, I lost tracking myself.
That's why I missed Jonathans fix and learned today 9e08273 != a93e53018
Thanks for the patience, (and sorry for the noise)
/Torsten