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

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

[Torsten Bögershausen]

Since commit f66caa "do not overwrite files in leading path"
at one place lstat() was called but the result was not checked.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
(While I was experimenting with something different, 
this was found by valgrind)
Please review the patch, comments wellcome.

 unpack-trees.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/unpack-trees.c b/unpack-trees.c
index 1ca41b1..42f7aad 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1374,10 +1374,9 @@ static int verify_absent_1(struct cache_entry *ce,
 		char path[PATH_MAX + 1];
 		memcpy(path, ce->name, len);
 		path[len] = 0;
-		lstat(path, &st);
-
-		return check_ok_to_remove(path, len, DT_UNKNOWN, NULL, &st,
-				error_type, o);
+		if (!lstat(path, &st))
+			return check_ok_to_remove(path, len, DT_UNKNOWN, NULL, &st,
+			                          error_type, o);
 	} else if (!lstat(ce->name, &st))
 		return check_ok_to_remove(ce->name, ce_namelen(ce),
 				ce_to_dtype(ce), ce, &st,
-- 
1.7.4

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

[Matthieu Moy]

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?

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.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Torsten Bögershausen]

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.
Not checking the return value (error or not) is not a good thing.
Developers might be tempted to write unreliable code...
> 
> 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.
> 
Hm,
v1.7.4 says:
commit e39212ab08e8d37dda5d8fd32b54099fe01dbbdb
Merge: 716958c 9e08273
(so far so good)
My git looks like this:

static int verify_absent_1(struct cache_entry *ce,
				 enum unpack_trees_error_types error_type,
				 struct unpack_trees_options *o)
{
[snip]
	else if (len > 0) {
		char path[PATH_MAX + 1];
		memcpy(path, ce->name, len);
		path[len] = 0;
		lstat(path, &st);
                ^^^^^^^^^^^^^^^^^^
		return check_ok_to_remove(path, len, DT_UNKNOWN, NULL, &st,
				error_type, o);


(And I had to correct drizzd@aon.a -> drizzd@aon.at)
/Torsten

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

[Matthieu Moy]

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 ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Torsten Bögershausen]

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