On Sun, Jul 01, 2007 at 00:35:04 +0200, Alex Riesen wrote: > Johannes Schindelin, Sat, Jun 30, 2007 16:31:48 +0200: > > On Sat, 30 Jun 2007, Alex Riesen wrote: > > > Johannes Schindelin, Thu, Jun 28, 2007 16:07:17 +0200: > > > > > No. It was meant as Alex said it. Windows (MinGW) doesn't understand > > > > > "chmod a+x blub". > > > > > > > > Yes, I suspected that. But I don't see a need for it on Windows (MinGW) to > > > > begin with. > > > > > > > > > > But it is necessary on Windows (Cygwin): > > > > I thought that on Cygwin, filemode=1? I mean, Cygwin _never_ had problems > > with chmod under my fingers. > > > > Try doing stat(2) on file.txt which contains "#!/bin/sh" in its first > line and for which you have issued a chmod yet. Like a new file, or > like every file in a git-tracked directory after you did a fresh > checkout. Cygwin actually opens the files when doing stat(2), looks > inside and tries to guess if they are executable. > > You should have said: "Cygwin _never_ had problems with chmod because > it cannot and didn't make it work". It is not just chmod, the other > side, stat, matters as well. I always had the impression, that cygwin actually *implements* chmod and does so using windows ACLs. And in ACL windows *do* support executable bit (I copied some DLL with cygwin copy and it was NOT executable then). Of course this only works on filesystems (NTFS, NTFS exported over CIFS) that support ACLs. On FAT it might be doing something like you describe. Though it is mostly irrelevant for git, because git does not work on FAT (Cygwin only supports posix rename on NTFS). -- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
