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
Subject: Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
Date: Mon, 16 Feb 2015 11:06:06 -0800 [thread overview]
Message-ID: <xmqqsie565i9.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <vpqtwyl90mx.fsf@anie.imag.fr> (Matthieu Moy's message of "Mon, 16 Feb 2015 19:23:02 +0100")
Matthieu Moy <Matthieu.Moy@grenoble-inp•fr> 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?
next prev parent reply other threads:[~2015-02-16 19:06 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
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 [this message]
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=xmqqsie565i9.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 \
/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