Re: [Bug] Permissions of temp file created in git's sha1_file.c correct?

From: Jakub Narebski <jnareb@gmail.com>
Date: Feb 2, 2011, 12:47 UTC
Message-ID: <m3vd128uz7.fsf@localhost.localdomain>
In-Reply-To: <5dfd4de157546244c86acd52564247ce@kloeckner.org>

Daniel Höpfl <daniel@hoepfl.de> writes:

Show 6 quoted lines

> Hello,
> 
> I recently (very recently: yesterday) started using git. I switched from
> Bazaar, that required me to have a file system that supports the executable
> flag (as it always stores this flag based on what the file system says).
> FAT does not support the executable flag.

That is why there is `core.fileMode` config variable, see git-config(1) manpage:

   core.fileMode
         If false, the executable bit differences between the index  and  the
         working copy are ignored; useful on broken filesystems like FAT. See
         git-update-index(1).

         The default is true, except git-clone(1) or git-init(1)  will  probe
         and  set  core.fileMode  false if appropriate when the repository is
         created.

Didin't git detect that it was on such filesystem?

[...]

> I think that my file system is right (of course ;-) ): A file that is not
> writable must not be renamed (arguable as the name could be seen as the
> content of the containing directory) and it must not be deleted.

Not true. Whether file can be renamed or deleted is governed by permissions in directory that contains given file, not the file itself (at least on POSIX). If I understand things correctly, of course.

Note that git doesn't store full permissions, in particular read/write permissions, only executable bit and "is symlink" thing.

-- 
Jakub Narebski
Poland
ShadeHawk on #git