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

Matthieu Moy [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

in compat/broken-unlink.c and something like this

	#ifdef BROKEN_UNLINK
	#define unlink(x) workaround_broken_unlink(x)
        #endif

in git-compat-util.h instead? 

That means we have to know BROKEN_UNLINK at compile-time. I had never
heard about AFP before this thread, but they seem mountable on Linux and
Windows. I don't know whether these platforms will have the same issue,
but I suspect they will (if the server rejects the unlink).

So, if my suspicion is right, we'd have to activate it on any platform
able to mount AFP, i.e. essentially everywhere.

Sigh.

quoted

That way, people on well behaving systems do not have to worry about
clobbering errno and stuff, perhaps?

With my solution, unlink() is always the last call in the function, so
it should behave correctly right? Or did I miss anything?

I am primarily worried about blindly attempting to run chmod() after
seeing a failure from the first unlink() _without_ even making sure
that the failure is caused by this silly bug in a single filesystem.

If the first unlink() failed for some other reason, chmod()
succeeded, and then the second unlink() failed for the same reason
as the first failure (because the mode bits of the file being
unlinked did not have anything to do with it), that would leave a
file with wrong permission bits.  And doing so when the user may
know that there is no AFP involved in her set-up would be doubly
wrong, no?