Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

[Junio C Hamano <gitster@pobox.com>]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> The issue is that having object and pack files read-only on the
> filesystem is a safety feature to prevent accidental modifications (even
> though it's actually not that effective, since brute-force "sed -i" or
> "perl -i" still accept to modify read-only files).

I did not see it as a "safety feature", and instead saw it as a
reminder to me that I am not supposed to write into them when I
check them with "ls -l".

> So, I'd be a bit reluctant to remove this safety feature for all users
> if it's only for the benefit of a minority of users. Not that I think
> the problem shouldn't be fixed, but I'd rather investigate alternate
> solutions before using this mode = 0644.

I fully agree with you that this should not be unconditional.
However, I am not sure if there is an effective workaround to a
filesystem that pays attention to the mode bits of the file when
doing an operation on the directory the file is sitting within.  It
may be OK to introduce a new configuration variable, perhaps call it
core.brokenFileSystemNeedsWritableFile or something, and probe and
enable it inside init_db().

But I suspect that the single "mode = 0444" under discussion may not
cover all places we create files, as the assumption that the we get
a sane semantics from the filesystem permeates throughout the code.

What other glitches does AFP have?  Does it share Windows' "you
cannot rename a file you have an open file descriptor on?"  Anything
else?