Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> 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? -- 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