All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Turner <dturner@twopensource.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Sixt <j.sixt@viscovery.net>,
	git@vger.kernel.org, David Turner <dturner@twitter.com>
Subject: Re: [PATCH 2/2] ignorecase: Fix git mv on insensitive filesystems
Date: Wed, 07 May 2014 11:01:06 -0700	[thread overview]
Message-ID: <1399485666.11843.68.camel@stross> (raw)
In-Reply-To: <xmqqha51bhxg.fsf@gitster.dls.corp.google.com>

On Wed, 2014-05-07 at 10:46 -0700, Junio C Hamano wrote:
> David Turner <dturner@twopensource.com> writes:
> 
> > On Wed, 2014-05-07 at 08:17 +0200, Johannes Sixt wrote:
> >> >  		} else if (cache_name_pos(src, length) < 0)
> >> >  			bad = _("not under version control");
> >> > -		else if (lstat(dst, &st) == 0) {
> >> > +		else if (lstat(dst, &dst_st) == 0 &&
> >> > +			 (src_st.st_ino != dst_st.st_ino ||
> >> > +			  (src_st.st_ino == 0 && strcasecmp(src, dst)))) {
> >> 
> >> Don't do that. st_ino is zero on Windows only because we do not spend time
> >> to fill in the field. Don't use it as an indicator for a case-insensitive
> >> file system; zero may be a valid inode number on other systems.
> >
> > I don't think it is a problem if zero is a valid inode.  The only thing
> > that happens when there is a zero inode, is that we have to compare
> > filenames.  The inode check is just an optimization to avoid doing a
> > bunch of strcasecmp on systems that don't have to.
> 
> Am I correct to rephrase you that the code assumes that any
> filesystem that cannot give unique inum to different files will use
> 0 as the placeholder inum, so if src/dst share the same non-zero
> inum, it is guaranteed that is not a placeholder and we know they
> are different files without comparing the two paths?

Yes, this is indeed a fair rephrasing.  In fact, the entire zero-check
should not be necessary, as POSIX requires that the st_ino field has a
"meaningful" value.  So in the case that this ever runs into a problem,
we ought to wrap the lstat call with a compatibility layer anyway. 

But maybe there is an OS I'm not thinking of which fills in st_ino with
something else?

  reply	other threads:[~2014-05-07 18:01 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-29 19:02 Bug: Case-insensitive filesystems can cause merge and checkout problems David Turner
2014-05-02  0:21 ` [PATCH] merge-recursive.c: Fix case-changing merge bug David Turner
2014-05-06 17:07   ` Junio C Hamano
2014-05-06 17:36     ` David Turner
2014-05-06 19:46       ` Junio C Hamano
2014-05-06 22:59         ` [PATCH 1/2] merge-recursive.c: Fix case-changing merge dturner
2014-05-06 22:59           ` [PATCH 2/2] ignorecase: Fix git mv on insensitive filesystems dturner
2014-05-07  6:17             ` Johannes Sixt
2014-05-07 16:42               ` David Turner
2014-05-07 17:46                 ` Junio C Hamano
2014-05-07 18:01                   ` David Turner [this message]
2014-05-08  6:37                   ` Johannes Sixt
2014-05-08  8:55                     ` Torsten Bögershausen
2014-05-08 17:23                       ` [PATCH 0/2] " dturner
2014-05-08 17:23                         ` [PATCH 1/2] merge-recursive.c: Fix case-changing merge dturner
2014-05-08 19:45                           ` Junio C Hamano
2014-05-08 17:23                         ` [PATCH 2/2] ignorecase: Fix git mv on insensitive filesystems dturner
2014-05-08 19:54                           ` Junio C Hamano
2014-05-08 20:40                             ` David Turner
2014-05-08 20:55                               ` Junio C Hamano
2014-05-08  1:22             ` brian m. carlson
2014-05-07 18:01           ` [PATCH 1/2] merge-recursive.c: Fix case-changing merge Junio C Hamano
2014-05-07 18:13             ` Jonathan Nieder
2014-05-07 20:53               ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2014-05-08 20:48 [PATCH 2/2] ignorecase: Fix git mv on insensitive filesystems Thomas Braun

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=1399485666.11843.68.camel@stross \
    --to=dturner@twopensource.com \
    --cc=dturner@twitter.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j.sixt@viscovery.net \
    /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.