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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 16, 2015, 19:06 UTC
Message-ID: <xmqqsie565i9.fsf@gitster.dls.corp.google.com>
In-Reply-To: <vpqtwyl90mx.fsf@anie.imag.fr>

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?