Re: [PATCH] Define a version of lstat(2) specially for copy operation
- From
Johannes Sixt <j.sixt@viscovery.net>
- Date
- Mar 18, 2009, 07:56 UTC
- Message-ID
- <49C0A919.7070606@viscovery.net>
- In-Reply-To
- <7vmybjl1l6.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
Show 28 quoted lines
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> So that Cygwin port can continue work around its supporting
>> library and get access to its faked file attributes.
>>
>> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
>> ...
>> diff --git a/builtin-init-db.c b/builtin-init-db.c
>> index ee3911f..f3f781b 100644
>> --- a/builtin-init-db.c
>> +++ b/builtin-init-db.c
>> @@ -66,7 +66,7 @@ static void copy_templates_1(char *path, int baselen,
>> else
>> exists = 1;
>>
>> - if (lstat(template, &st_template))
>> + if (lstat_for_copy(template, &st_template))
>> die("cannot stat template %s", template);
>>
>> if (S_ISDIR(st_template.st_mode)) {
>
> Yuck; that's a bit too ugly for generic code. Will there be other places
> that this needs to be used? If so, we'd probably need to encourage its
> use where appropriate, which is even uglier but we cannot avoid it...
>
> Also when the underlying system does not know the executable bit, how
> would this help? I thought that earlier you said the part that checks if
> it wants to execute hooks with access(X_OK) will fail, so...The "underlying system" in this case is Cygwin, and it *does* have an executable bit.
But the FS gymnastics that implement it are slow and affect all lstat() calls, so we have replaced lstat() with a simpler and faster implementation. Only that the replacement doesn't know about the X bit anymore; it always returns mode 0666.
Therefore, if a file is created whose mode is influenced by the fast lstat(), then it will always be non-X. The access(, X_OK) call on the hook script would do the right thing if only the script were created with the correct mode. access(, X_OK) fails because the file was created with non-X permissions.
-- Hannes