git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: "Torsten Bögershausen" <tboegi@web.de>,
	"Eric Sunshine" <sunshine@sunshineco.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Eric Wong <normalperson@yhbt.net>,
	Karsten Blees <karsten.blees@gmail.com>,
	Stefan Beller <stefanbeller@gmail.com>,
	Matthieu Moy <Matthieu.Moy@imag.fr>,
	Git List <git@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] create_default_files(): don't set u+x bit on $GIT_DIR/config
Date: Mon, 17 Nov 2014 12:32:30 +0100	[thread overview]
Message-ID: <5469DCCE.8040801@alum.mit.edu> (raw)
In-Reply-To: <5469BAFA.7070709@web.de>

On 11/17/2014 10:08 AM, Torsten Bögershausen wrote:
> On 11/17/2014 02:40 AM, Eric Sunshine wrote:
>> On Sun, Nov 16, 2014 at 2:21 AM, Michael Haggerty
>> <mhagger@alum.mit.edu> wrote:
>>> [...]
> Sorry for the late reply, I actually had prepared a complete different
> patch
> for a different problem, but it touches the very same lines of code.
> 
> (And we may want to add a
> !chmod(path, st1.st_mode & ~S_IXUSR)
> at the end of the operation)
> 
> There are systems when a file created with 666 have 766, and we
> do not handle this situation yet.
> 
> Michael, if there is a chance that you integrate my small code changes
> in your patch ?

Your change seems like a good idea, but is is logically separate from
mine and I think it would be awkward to yoke them together. Both changes
are short enough that conflict resolution shouldn't be a big problem.

It will be easier for you to follow up on your patch if you submit it
separately. The first question you get might be: "Should it be applied
to maint or is it more suitable for master?", which also hints at one of
the reasons that yoking the patches together might be awkward.

Regarding your patch itself:

> [...]
>     b) The user executable bit is always 1
>     c) Is similar to b):
>        When a file is created with mode 0666 the file mode on disc is 766
>        and the user executable bit is 1 even if it should be 0 like b)
> 
>        There are smbfs implementations where the file mode can be maintained
>        locally and chmod -x changes the file mode from 0766 to 0666.
>        When the file system is unmounted and remounted,
>        the file mode is 0766 and executable bit is 1 again.

It seems surprising that there isn't also a case (d) like (c) except
that a file created with mode 0666 initially has the correct mode, and
the executable bits can be maintained locally while the filesystem is
mounted, but where executable bits are lost whenever the filesystem is
unmounted and remounted. Does that case not arise, or is it simply that
it is impossible to test for it in create_default_files()?

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu

  reply	other threads:[~2014-11-17 11:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-16  7:21 [PATCH v2 0/2] Don't make $GIT_DIR executable Michael Haggerty
2014-11-16  7:21 ` [PATCH v2 1/2] create_default_files(): don't set u+x bit on $GIT_DIR/config Michael Haggerty
2014-11-16 19:08   ` Junio C Hamano
2014-11-17  9:35     ` Michael Haggerty
2014-11-17  1:40   ` Eric Sunshine
2014-11-17  9:08     ` Torsten Bögershausen
2014-11-17 11:32       ` Michael Haggerty [this message]
2014-11-17  9:46     ` Michael Haggerty
2014-11-17 15:42       ` Junio C Hamano
2014-11-17 16:19         ` Michael Haggerty
2014-11-17 16:43           ` Junio C Hamano
2014-11-16  7:21 ` [PATCH v2 2/2] config: clear the executable bits (if any) " Michael Haggerty
2014-11-16  8:06   ` Johannes Sixt
2014-11-17  9:03     ` Michael Haggerty

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=5469DCCE.8040801@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=Matthieu.Moy@imag.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karsten.blees@gmail.com \
    --cc=normalperson@yhbt.net \
    --cc=stefanbeller@gmail.com \
    --cc=sunshine@sunshineco.com \
    --cc=tboegi@web.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).