Alex Riesen <raa.lkml@xxxxxxxxx> writes: > Johannes Sixt, Tue, Mar 17, 2009 17:59:09 +0100: >> Junio C Hamano schrieb: >> > Alex Riesen <raa.lkml@xxxxxxxxx> writes: >> > >> >> It is broken because of the tricks we have to play with >> >> lstat to get the bearable perfomance out of the call. >> >> Sadly, it disables access to Cygwin's executable attribute, >> >> which Windows filesystems do not have at all. >> > >> > Hmm, perhaps when checking hooks to see if they are executable, Cygwin >> > port should avoid using the "tricks"? Compared to paths inside the >> > worktree the number of hooks is a lot smaller, no? >> >> Hmm. Nowadays, we run hooks through run_hook() in run_command.c. It uses > > The problem is that copy_templates_1 does an lstat on the files in > templates directory and gets 0666 mode (regular file, non-exec) for > executable file under current Cygwin port. The st_mode of that lstat > is passed to copy_file mentioned, which is useless now as we use the > Win32 version of lstat, which doesn't do x-bit. Ahhh. I do not mind the patch as a band-aid to make the testsuite pass, so I'll apply your patch as-is. Thanks. But isn't this something shops that do deploy Cygwin version of git want to see fixed, so that they can have a site-wide policy implemented in the hooks copied from templates? I think we could pass mode 0 to copy_files() and have the function special case it (and allow a platform specific copy_files() implementated by Cygwin). lstat() in the copy_templates_1() codepath is primarily done to see if we need to descend into a directory or symlink() and our use of st.st_mode to pass to copy_files() is a no cost side effect on platforms with x-bit support. >> access(..., X_OK), not lstat(). We don't play games with access(), do we? > > access(..., X_OK) will return -1. That codepath would also need to be fixed if Cygwin wants to use hooks, I would guess. -- 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