From: Junio C Hamano <gitster@pobox.com>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: git@vger.kernel.org, zwanzig12@googlemail.com,
stefanbeller@googlemail.com, kusmabite@gmail.com,
Johannes.Schindelin@gmx.de, msysgit@googlegroups.com
Subject: Re: [PATCH] repack.c: chmod +w before rename()
Date: Fri, 24 Jan 2014 15:31:46 -0800 [thread overview]
Message-ID: <xmqq1tzxq7ml.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <201401242205.16313.tboegi@web.de> ("Torsten Bögershausen"'s message of "Fri, 24 Jan 2014 22:05:14 +0100")
Torsten Bögershausen <tboegi@web.de> writes:
> Another solution could be to do the "chmod +x" in mingw_rename().
> This may be done in another commit, because
> a) It improves git gc only when Git for Windows is used
> on the client machine
> b) Windows refuses to delete a file when the file is read-only.
> So setting a file to read-only under Windows is a way for a user
> to protect it from being deleted.
> Changing the behaviour of rename() globally may not be what we want.
But doesn't this affect non Windows platforms in negative ways? We
unconditionally run stat(2) and chmod(2) unnecessarily, and we leave
the resulting file writable when it originally may have been marked
read-only on purpose.
Also, it feels to me that doing this in mingw_rename() the right
approach in the first place. If the user wants "git mv a b" to
rename "a" in the working tree and if that path is read-only, what
happens, and what should happen? Does "chmod -w" on a file in the
working tree mean "I want to make sure nobody accidentally writes to
it, and also I want to protect it from being renamed or deleted"?
So perhaps mingw_rename() can be taught to
- First try to just do rename(), and if it succeeds, happily return
without doing anything extra.
- If it fails, then
- check if the failure is due to read-only-ness (optional: if you
cannot reliably tell this from the error code, do not bother),
and if not, return failure.
- otherwise, stat() to grab the current permission bits, do the
chmod(), retry the rename, then restore the permission bits
with another chmod(). Return failure if any of these steps
fail.
That way, it can cover any call to rename(), be it for packfiles or
a path in the working tree, and you would need to pay the overhead
of stat/chmod only when it matters, no?
> Reported-by: Jochen Haag <zwanzig12@googlemail.com>
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
> builtin/repack.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/builtin/repack.c b/builtin/repack.c
> index ba66c6e..033b4c2 100644
> --- a/builtin/repack.c
> +++ b/builtin/repack.c
> @@ -324,6 +324,10 @@ int cmd_repack(int argc, const char **argv, const char *prefix)
> statbuffer.st_mode &= ~(S_IWUSR | S_IWGRP | S_IWOTH);
> chmod(fname_old, statbuffer.st_mode);
> }
> + if (!stat(fname, &statbuffer)) {
> + statbuffer.st_mode |= (S_IWUSR | S_IWGRP | S_IWOTH);
> + chmod(fname, statbuffer.st_mode);
> + }
> if (rename(fname_old, fname))
> die_errno(_("renaming '%s' failed"), fname_old);
> free(fname);
> --
> 1.9.rc0.143.g6fd479e
>
> --
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
prev parent reply other threads:[~2014-01-24 23:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-24 21:05 [PATCH] repack.c: chmod +w before rename() Torsten Bögershausen
2014-01-24 21:40 ` brian m. carlson
2014-01-24 22:24 ` Johannes Schindelin
2014-01-24 22:49 ` brian m. carlson
2014-01-24 23:50 ` Mike Hommey
2014-01-24 23:32 ` Junio C Hamano
2014-01-24 23:31 ` Junio C Hamano [this message]
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=xmqq1tzxq7ml.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=kusmabite@gmail.com \
--cc=msysgit@googlegroups.com \
--cc=stefanbeller@googlemail.com \
--cc=tboegi@web.de \
--cc=zwanzig12@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.