[1.7] recursive /cygdrive problem

[1.7] recursive /cygdrive problem

[Shaddy Baddah]

Hi,

I am having a real problem with 1.7 that I am pretty sure is a 
regression. Basically, I am trying to run a find over the cygwin root 
installation directory itself, not from cygwin path /. However I am 
finding that the cygdrive directory at the cygwin root installation 
directory also mounts my drives. So, my find is finding a hole to make 
its way out of the current directory. This also appears to be a 
regression. The following is an example for 1.7:

Shaddy@x-vista ~
$ uname -a
CYGWIN_NT-6.0 x-vista 1.7.0(0.212/5/3) 2009-09-11 01:25 i686 Cygwin

Shaddy@x-vista ~
$ mount
C:/software/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/software/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/software/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
E: on /cygdrive/e type ntfs (binary,posix=0,user,noumount,auto)

Shaddy@x-vista ~
$ cd /cygdrive/c/software/cygwin/

Shaddy@x-vista /cygdrive/c/software/cygwin
$ ls ./cygdrive
c  d  e

Shaddy@x-vista /cygdrive/c/software/cygwin
$

where as 1.5:

Shaddy@x-vista ~
$ uname -a
CYGWIN_NT-6.0 x-vista 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin

Shaddy@x-vista ~
$ mount
C:\software\cygwin-1.5\bin on /usr/bin type system (binmode)
C:\software\cygwin-1.5\lib on /usr/lib type system (binmode)
C:\software\cygwin-1.5 on / type system (binmode)
c: on /cygdrive/c type system (binmode,noumount)
d: on /cygdrive/d type system (binmode,noumount)
e: on /cygdrive/e type system (binmode,noumount)

Shaddy@x-vista ~
$ cd /cygdrive/c/software/cygwin-1.5

Shaddy@x-vista /cygdrive/c/software/cygwin-1.5
$ ls ./cygdrive

Shaddy@x-vista /cygdrive/c/software/cygwin-1.5
$

Genuine bug?

Thanks in advance,
Shaddy


--
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

Re: [1.7] recursive /cygdrive problem

[Larry Hall (Cygwin)]

On 09/16/2009 11:24 AM, Shaddy Baddah wrote:
> Hi,
>
> I am having a real problem with 1.7 that I am pretty sure is a
> regression. Basically, I am trying to run a find over the cygwin root
> installation directory itself, not from cygwin path /. However I am
> finding that the cygdrive directory at the cygwin root installation
> directory also mounts my drives. So, my find is finding a hole to make
> its way out of the current directory. This also appears to be a
> regression. The following is an example for 1.7:

<snip>

> Shaddy@x-vista /cygdrive/c/software/cygwin
> $ ls ./cygdrive
> c d e

<snip>

> Shaddy@x-vista /cygdrive/c/software/cygwin-1.5
> $ ls ./cygdrive

<snip>

> Genuine bug?

No, a feature.  Having the existing drives show up under '/cygdrive' is a 
convenience
for things like bash and other shells so that they can do completion on the 
paths to
these drives.  If you don't want what's under the '/cygdrive' directory, you 
can omit
it from your invocation of 'find'.


-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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

Re: [1.7] recursive /cygdrive problem

[Shaddy Baddah]

Hi Larry,

Larry Hall (Cygwin) wrote:
>
> <snip>
>
>> Genuine bug?
>
> No, a feature.  Having the existing drives show up under '/cygdrive' 
> is a convenience
> for things like bash and other shells so that they can do completion 
> on the paths to
> these drives.  If you don't want what's under the '/cygdrive' 
> directory, you can omit
> it from your invocation of 'find'.
>

Respectfully, I think you've misunderstood my problem. I've just
posted a followup which will show an out and out inconsistency (well,
at least in my opinion):

Shaddy@x-vista ~
$ ls /cygdrive/c/software/cygwin/cygdrive

Shaddy@x-vista ~
$ cd /cygdrive/c/software/cygwin/

Shaddy@x-vista /cygdrive/c/software/cygwin
$ ls ./cygdrive
c  d  e

Shaddy@x-vista /cygdrive/c/software/cygwin
$

IMO, the result of the first ls is the more logical. It at least is
consistent with 1.5 if anything else (not that this is a strong
argument).

Regards,
Shaddy


--
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

Re: [1.7] recursive /cygdrive problem

[Larry Hall (Cygwin)]

On 09/16/2009 11:55 AM, Shaddy Baddah wrote:
> Respectfully, I think you've misunderstood my problem. I've just
> posted a followup which will show an out and out inconsistency (well,
> at least in my opinion):
>
> Shaddy@x-vista ~
> $ ls /cygdrive/c/software/cygwin/cygdrive
>
> Shaddy@x-vista ~
> $ cd /cygdrive/c/software/cygwin/
>
> Shaddy@x-vista /cygdrive/c/software/cygwin
> $ ls ./cygdrive
> c  d  e
>
> Shaddy@x-vista /cygdrive/c/software/cygwin
> $
>
> IMO, the result of the first ls is the more logical. It at least is
> consistent with 1.5 if anything else (not that this is a strong
> argument).

Yes, this message (and the one you sent about the time I sent my first reply)
clarify the issue, at least for me.  I can reproduce it, though I haven't 
looked
into it more.  I can say I tried testing 'du' to see if I could see 
recursion and,
somewhat surprisingly (to me), I didn't.  To me however, if we're looking for
consistency, I would say that the results of both invocations of 'ls' above 
should
show the list of drives.

FWIW, I think you'll find Cygwin 1.5 behaves the same if you create a 'cygdrive'
(or whatever your cygdrive prefix is called) directory in your '/'.  I may 
be wrong
though.  I haven't tried this.

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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

Re: [1.7] recursive /cygdrive problem

[Corinna Vinschen]

On Sep 17 01:55, Shaddy Baddah wrote:
> Hi Larry,
>
> Larry Hall (Cygwin) wrote:
>>
>> <snip>
>>
>>> Genuine bug?
>>
>> No, a feature.  Having the existing drives show up under '/cygdrive'  
>> is a convenience
>> for things like bash and other shells so that they can do completion  
>> on the paths to
>> these drives.  If you don't want what's under the '/cygdrive'  
>> directory, you can omit
>> it from your invocation of 'find'.
>>
>
> Respectfully, I think you've misunderstood my problem. I've just
> posted a followup which will show an out and out inconsistency (well,
> at least in my opinion):
>
> Shaddy@x-vista ~
> $ ls /cygdrive/c/software/cygwin/cygdrive
>
> Shaddy@x-vista ~
> $ cd /cygdrive/c/software/cygwin/
>
> Shaddy@x-vista /cygdrive/c/software/cygwin
> $ ls ./cygdrive
> c  d  e
>
> Shaddy@x-vista /cygdrive/c/software/cygwin
> $
>
> IMO, the result of the first ls is the more logical. It at least is
> consistent with 1.5 if anything else (not that this is a strong
> argument).

It's a bug nevertheless.  I introduced it in May, when I tried to
workaround a problem with a stored cwd using non-ASCII chars in case
the application switches the locale.  The idea was to store the path
only as Windows path and evaluate the matching posix path only on
first usage.  Unfortunately that results in an unwanted side-effect:

  $ cd /cygdrive/c/cygwin
  $ pwd
  /

I fixed this problem now differently.  When setlocale is called, the
path of the current working dir is actually converted from the old
charset to the new charset.


Thanks for the report,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

Re: [1.7] recursive /cygdrive problem

[Shaddy Baddah]

Hi Larry,

Larry Hall (Cygwin) wrote:
>
> <snip>
>
>> Genuine bug?
>
> No, a feature.  Having the existing drives show up under '/cygdrive' 
> is a convenience
> for things like bash and other shells so that they can do completion 
> on the paths to
> these drives.  If you don't want what's under the '/cygdrive' 
> directory, you can omit
> it from your invocation of 'find'.
>

Respectfully, I think you've misunderstood my problem. I've just
posted a followup which will show an out and out inconsistency (well,
at least in my opinion):

Shaddy@x-vista ~
$ ls /cygdrive/c/software/cygwin/cygdrive

Shaddy@x-vista ~
$ cd /cygdrive/c/software/cygwin/

Shaddy@x-vista /cygdrive/c/software/cygwin
$ ls ./cygdrive
c  d  e

Shaddy@x-vista /cygdrive/c/software/cygwin
$

IMO, the result of the first ls is the more logical. It at least is
consistent with 1.5 if anything else (not that this is a strong
argument).

Regards,
Shaddy


--
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

Re: [1.7] recursive /cygdrive problem

[Shaddy Baddah]

Hi again,

Shaddy Baddah wrote:
> The following is an example for 1.7:
>
> Shaddy@x-vista ~
> $ cd /cygdrive/c/software/cygwin/
>
> Shaddy@x-vista /cygdrive/c/software/cygwin
> $ ls ./cygdrive
> c  d  e
It has occurred to me that this wasn't the optimal example, as it does 
not eliminate a problem with the cd command. Take two is more revealing:

Shaddy@x-vista ~
$ ls /cygdrive/c/software/cygwin/cygdrive

Shaddy@x-vista ~
$

ie. no problem without the cd command. To eliminate bash builtin cd 
being a problem (not that it really would/should), here is some python:

Shaddy@x-vista ~
$ python
Python 2.5.2 (r252:60911, Dec  2 2008, 09:26:14)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import os
 >>> os.chdir('/cygdrive/c/software/cygwin')
 >>> os.listdir('./cygdrive')
['c', 'd', 'e']
 >>>

So what gives with the chdir implementation? Oh, and I originally ran 
into the problem trying to run du against the subdirs, not find. However 
the problem presents with find as well of course.

Regards,
Shaddy


--
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