git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: "Randal L. Schwartz" <merlyn@stonehenge.com>,
	Johannes Sixt <j6t@kdbg.org>, Pat Thoyts <patthoyts@gmail.com>,
	msysGit <msysgit@googlegroups.com>,
	Sebastian Schuberth <sschuberth@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] Do not trust PWD blindly
Date: Mon, 11 Jul 2011 09:56:52 -0700	[thread overview]
Message-ID: <7vbox0g3hn.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.DEB.1.00.1107111121390.3379@bonsai2> (Johannes Schindelin's message of "Mon, 11 Jul 2011 11:26:34 +0200 (CEST)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Sun, 10 Jul 2011, Randal L. Schwartz wrote:
> ...
>> If you ever depend on a userspace PWD to be your actual current 
>> directory without at least stat()ing it, you've failed.
>> 
>> In my experience, it is *never* reliable.  It's just a hint.
>
> To be precise, get_pwd_cwd() _does_ stat() what's in PWD, and _does_ 
> compare with the stat() of what comes out of getcwd(), but that comparison 
> uses only st_dev and st_ino, both of which happen to be 0 in my case -- 
> for each and every file/directory.
>
> I can only _guess_ at the reasoning behind get_pwd_cwd(). I _think_ it was 
> meant to catch the case when getcwd() and PWD refer to the same directory, 
> but PWD goes through symbolic links.

Thanks for a much clearer explanation than before. I tried to reword the
proposed commit log message using the description above.

I feel that the title is still not optimal. If the original code used to
return getenv("PWD") if the environment variable is set, and otherwise
fell back to getcwd(), and the updated code tries to make sure they refer
to the same directory, then "Do not trust PWD blindly" would be a good
description for the fix, but the code you fixed the bug in tried not to
trust PWD blindly but failed to realize that on some systems dev/ino field
may be unreliable.

"Do not trust st.st_ino/st.st_dev blindly" might be a better title in that
sense.

In any case, thanks for a fix; will queue.

Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date:   Sat Jul 9 19:38:08 2011 +0200

    Do not trust PWD blindly
    
    10c4c88 (Allow add_path() to add non-existent directories to the path,
    2008-07-21) introduced get_pwd_cwd() function in order to favor $PWD when
    getenv("PWD") and getcwd() refer to the same directory but are different
    strings (e.g. the former gives a nicer looking name via a symbolic link to
    an uglier looking automounted path). The function tried to determine if
    two directories are the same by running stat(2) on both and comparing
    ino/dev fields.
    
    Unfortunately, stat() does not fill any ino or dev fields in msysgit.  But
    there is a telltale: both ino and dev are 0 when they are not filled
    correctly, so let's be extra cautious.
    
    This happens to fix a bug in "get-receive-pack working_directory/" when
    the GIT_DIR would not be set correctly due to absolute_path(".")
    returning the wrong value.
    
    Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    Acked-by: Johannes Sixt <j6t@kdbg.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

  reply	other threads:[~2011-07-11 16:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CABNJ2GKgzXGDq9FhKcVP380bs=rEKqYdrOaCb+A99_TBm7A4_A@mail.gmail.com>
2011-07-09 17:38 ` [PATCH] Do not trust PWD blindly Johannes Schindelin
2011-07-09 20:06   ` Sebastian Schuberth
2011-07-10 20:47   ` Johannes Sixt
2011-07-10 22:59     ` Johannes Schindelin
2011-07-11  1:52       ` Randal L. Schwartz
2011-07-11  9:26         ` Johannes Schindelin
2011-07-11 16:56           ` Junio C Hamano [this message]
2011-07-11 17:18             ` Johannes Schindelin

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=7vbox0g3hn.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=merlyn@stonehenge.com \
    --cc=msysgit@googlegroups.com \
    --cc=patthoyts@gmail.com \
    --cc=sschuberth@gmail.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 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).