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

> 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?