Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> 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. > >> 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? -- 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