X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=GfPK7Zy+17y8l+Zr15iQN+ph2AdUIykCrXX7AtZt8W/
	QV5EYA+T4VOlHPqVT/X4pg9CZFM7yo7azPuXhINpMXBy+5yMy3SMIpVJJ9s7hH7u
	UHk2S+eJjosmUo9mCG5Hzi+Hbyv0PRj+bYur5Hzn9GDEEzVCiBlqbNAzJb5RnJCs
	=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 s=default; bh=QdXeN/KsIAqwfklNWRA2A3IdhrQ=; b=Tv7BMjzPh8UELoj36
	ltpXKgrCwC9ZMLCml+3KofGQDq2/1BfYSErxVNNHaBrxqSsBqsQ6QODohTKt8ZF/
	Az3oWIHpX4OJehXdcLYyVAk+kNONXUSCx8/YmrDvMdpbk64/TA7e39jZaO6Zlsmp
	JA+kbltt29qf5wfcIyMHiBEjHw=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Spam-SWARE-Status: No, score=-5.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KHOP_PGP_INLINE,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.2
X-Received: by 10.152.20.36 with SMTP id k4mr3224957lae.33.1377116770889;        Wed, 21 Aug 2013 13:26:10 -0700 (PDT)
Message-ID: <52152260.7080105@gmail.com>
Date: Thu, 22 Aug 2013 00:26:08 +0400
From: LRN <lrn1986 AT gmail DOT com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Thunderbird/26.0a1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: shell-init: error retrieving current directory
References: <CAHWeT-b80VyH382nXA2RrNmgK1jGOrFpw_t_zpJWEv7znR7pmA AT mail DOT gmail DOT com> <20130816134745 DOT GJ2562 AT calimero DOT vinschen DOT de>
In-Reply-To: <20130816134745.GJ2562@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16.08.2013 17:47, Corinna Vinschen wrote:
> On Aug 16 12:00, Andy Koppe wrote:
>> This might be the same issue as a couple of previous unresolved
>> reports with the same error message, but I'm not sure, so here's a new
>> thread.
>>
>> Steps to reproduce:
>> - On Windows 7, install 64-bit Cygwin into C:\cygwin, and let it
>> create a desktop shortcut.
>> - Edit /etc/fstab to change the cygdrive prefix to /.
>> - Double click 'Cygwin64 Terminal' desktop shortcut.
>>
>> Result: a bunch of errors before the bash prompt.
>>
>> shell-init: error retrieving current directory: getcwd: cannot access
>> parent directories: Bad file descriptor
>> job-working-directory: error retrieving current directory: getcwd:
>> cannot access parent directories: No such file or directory
>> job-working-directory: error retrieving current directory: getcwd:
>> cannot access parent directories: No such file or directory
>> job-working-directory: error retrieving current directory: getcwd:
>> cannot access parent directories: No such file or directory
>> chdir: error retrieving current directory: getcwd: cannot access
>> parent directories: No error
>>
>> The errors remain if the shortcut target is changed from invoking
>> mintty to invoking bash directly: 'C:\cygwin\bin\bash.exe -l'.
>>
>> The errors go away if 'C:\cygwin\bin' is put into the shortcut's
>> otherwise empty 'Start In' field. (But they stay if 'C:\' is put there
>> instead.)
>>
>> They also go away if the cygdrive prefix is changed to anything but
>> the root directory.
>>
>> I couldn't reproduce the issue with a 32-bit install.
> 
> I tried to find the cause for this issue, but as far as I can tell, it's
> not a problem in Cygwin.  For some reason bash seems to implement its
> own getcwd function, which plays a lot with calling stat on ., ..,
> ../.., etc.  All results from stat seem to make sense.  The error code
> itself (Bad file descriptor, etc) doesn't matter.  It's just some
> arbitrary value errno is set to at the time bash decides it doesn't like
> what the system calls return.  By tweaking the internal function which
> implements the core of the system getcwd function, I could return any
> error value at will.
> 
> Eric, can you please have a look into this issue?  Something's weird
> with bash's getcwd implementation which is apparently only triggered
> in the 64 bit version.

I've debugged this a bit, and here's what i see:
  Working directory is c:/foo

Bash does a stat on '/' and '.', remembers ino of '.' as 'thisino', ino
of '/' as 'rootino'. Same for dev (thisdev and rootdev).

Then does the following until it gets an error, or thisino == rootino &&
thisdev == rootdev (that is, until observed directory is '/'):
  dotp = '..'
  does stat on dotp ('..') (this is a stat on 'c:/' in our case)
  saves ino and dev to dotino and dotdev
  checks whether this directory is a mount point. It is a mount point
when dotdev != thisdev - that is, when going up the directory tree
caused a change in dev value. Whether this will work at all or not
depends on how Cygwin assigns dev numbers to directories.
  opens the directory dotp ('..'), which is c:/
  reads each entry in that directory, and for each entry that isn't '.'
or '..':
    if dotp was a mount point OR ino of the entry == thisino (that is,
it looks either for mount points, or for the previous directory, to
verify that '..' and previously observer directory are linked together
in the directory tree):
      grabs name of the entry, puts it into the buffer
      does lstat on the buffer, breaks the loop if stated ino and dev
match thisino and thisdev (i.e. checks for symlinks? not sure what's the
point)
  if an entry was found (i.e tree doesn't have holes):
    prepends name of the entry to cwd buffer
    updates thisdev and thisino
  otherwise:
    fails, returns NULL

next iteration:
  dotp = '../..'
  stat ('../..'). Due to cygwin's cleverness, this is a stat on
'c:/cygwin' (that is, '/'), not on 'c:/' (which it would normally be on
W32 - can't go above c:/)
  checks for mountpoints (not a mountpoint, at least in my case - there
was a transision from c:/ up to /, but dev didn't change) - not a mount
point
  opens the directory dotp ('../..'), which is 'c:/cygwin' or '/'
  reads each entry:
    checks whether the entry is the directory from the previous
iteration ('c:/'). This check always fails, because Cygwin doesn't list
/c in /
  since no entry is found, and this was not a mount point, getcwd()
fails and returns NULL


I remember someone pointing out that not listing local disks mountpoints
in / when cygdrive prefix is empty is a feature. Maybe not so much...

You might be able to fix this by forcing / to have a different dev number.


- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJSFSJgAAoJEOs4Jb6SI2CwgtoH/jAqrEy8BcFzV02D462kym3W
UXy39lBDnCGTl+mO9u3E+eNAH8SKvzdHyYk8y9sBrt2TTd9HZJMz6X9IgRRsTG/E
vUNXlh6O8i2/iK+aJcD1IfBo3CTA37N3VeHWCebPiMyGzjBM6cGqi0ycLGh8vpAj
qqV6zGpAzBEJv1gNEcjG49kk6OYsM//bGqDxRzP5nZvJFuGOlaGN0G3/X+6fq2Q7
ApT1VDb5JZ2FAzVdxh+j8bBbYJJ/gyDUrjCQXrBWSQC5PW3YRvA4z73a8IGspnkw
kXK+dE9MYyBvLLFjMjmjrZn1PNVvGypHsgh820EJQlZv90wFuDzr4y99q2hU5pQ=
=/iJK
-----END PGP SIGNATURE-----

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple