Jan Hudec, Sun, Jul 01, 2007 11:16:46 +0200: > 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 Windows ACLs don't have exec bit in the UNIX sense. > 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). It does not work on NTFS either. For all the same reason I described above: Cygwin tries to be clever (and annoying) and looks into files. And no Windows program (like, for example, your editor of preference) will call Cygwin's chmod just to set the permissions how Cygwin likes them. - 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
