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

Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:

This should be fixable from Git itself, by replacing the calls to "unlink" with something like

int unlink_or_chmod(...) {
	if (unlink(...)) {
		chmod(...); // give user write permission
		return unlink(...);
	}
}

This does not add extra cost in the normal case, and would fix this particular issue for afp shares. So, I think that would fix the biggest problem for afp-share users without disturbing others. It seems reasonable to me to do that unconditionnally.

What happens if you do "rm -fr oh-my-zsh/.git/objects/pack/" (i.e. remove the directory, not the files)?

If you can still remove the directory, then I'd say the solution above could be sufficient: the user isn't supposed to interfer with the content of .git/objects other than by using Git, and if he or she does, then asking a chmod prior to an rm seems reasonable.

If you can't, then it's another problematic use-case (basically, you can't just "rm -fr" a whole clone), and then it deserves at least an opt-in configuration to get writable pack files.

(Unfortunately, I suspect we're in the later case)

Yes. In case you hadn't guessed, this is precisely what I had in mind when I asked "Is it a problem when using Git [...] or when trying to remove files outside Git?".