From: Junio C Hamano <gitster@pobox•com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp•fr>
Cc: Fairuzan Roslan <fairuzan.roslan@gmail•com>,
git@vger•kernel.org, tboegi@web•de
Subject: Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
Date: Wed, 18 Feb 2015 09:13:10 -0800 [thread overview]
Message-ID: <xmqq4mqj3zyx.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <vpqwq3fup5g.fsf@anie.imag.fr> (Matthieu Moy's message of "Wed, 18 Feb 2015 18:04:43 +0100")
Matthieu Moy <Matthieu.Moy@grenoble-inp•fr> writes:
> Junio C Hamano <gitster@pobox•com> 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?
next prev parent reply other threads:[~2015-02-18 17:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-16 17:54 odb_mkstemp's 0444 permission broke write/delete access on AFP Fairuzan Roslan
2015-02-16 18:23 ` Matthieu Moy
2015-02-16 18:41 ` Fairuzan Roslan
2015-02-16 19:08 ` Matthieu Moy
2015-02-17 3:22 ` Fairuzan Roslan
2015-02-17 5:34 ` Torsten Bögershausen
2015-02-17 5:54 ` Fairuzan Roslan
2015-02-17 8:51 ` Matthieu Moy
2015-02-17 16:58 ` Fairuzan Roslan
2015-02-17 17:54 ` Torsten Bögershausen
2015-02-18 8:15 ` Matthieu Moy
2015-02-18 13:47 ` Fairuzan Roslan
2015-02-18 14:05 ` Matthieu Moy
2015-02-18 14:23 ` Fairuzan Roslan
2015-02-17 17:13 ` Junio C Hamano
2015-02-18 17:04 ` Matthieu Moy
2015-02-18 17:13 ` Junio C Hamano [this message]
2015-02-18 17:31 ` Junio C Hamano
2015-02-19 20:08 ` brian m. carlson
2015-02-20 10:40 ` Matthieu Moy
2015-02-16 19:06 ` Junio C Hamano
2015-02-16 19:50 ` Torsten Bögershausen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq4mqj3zyx.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=Matthieu.Moy@grenoble-inp$(echo .)fr \
--cc=fairuzan.roslan@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=tboegi@web$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox