Re: Snapshot 20000522

[Chris Faylor <cgf at cygnus dot com>]

But both of these are not recent problems and one may not even be a
problem at all.

I can't duplicate the problems with zip but I'm using the CD version, not
the CygUtils version.

cgf

On Tue, May 23, 2000 at 12:53:04PM -0700, Earnie Boyd wrote:
>--- Chris Faylor <cgf@cygnus.com> wrote:
>> On Tue, May 23, 2000 at 06:17:33AM -0700, Earnie Boyd wrote:
>> >I'll work up a better report later but I wanted to give a heads up that
>> >subjected snapshot has problems stat'ing a file.  Most evident with gdb. 
>> >Falling back to 1.1.0 doesn't have this problem.
>> 
>> I've been running gdb all morning with no problem so it's not a simple
>> problem, whatever it is.
>> 
>
>I still don't have a very good detail of this yet, however, this
>
>--- Jason Tishler <Jason.Tishler@dothill.com> wrote:
>> After upgrading from 1.1.0 to 1.1.1, I started to experience problems
>> using relative pathnames with mv when in my home directory:
>> 
>>     $ pwd
>>     /home/jt
>>     $ ls .foo 
>>     .foo
>>     $ mv .foo .foo2 
>>     mv: cannot move `.foo' to `.foo2': No such file or directory
>> 
>> But, the following using absolute pathnames works:
>> 
>>     $ ls ~/.foo
>>     /home/jt/.foo
>>     $ mv ~/.foo ~/.foo2
>>     $ ls ~/.foo2 
>>     /home/jt/.foo2
>> 
>> And, so does using relative pathnames with mv in a directory other than
>> my home directory:
>> 
>>     $ pwd
>>     /tmp
>>     $ ls .foo
>>     .foo
>>     $ mv .foo .foo2
>>     $ ls .foo2 
>>     .foo2
>> 
>> Note that the first case above works just fine under 1.1.0.
>
>and this,
>
>--- Jason Tishler <Jason.Tishler@dothill.com> wrote:
>-8<-
>> FYI, the current CygUtils version of zip does not properly handle
>> absolute pathnames as in the following:
>> 
>>     $ zip -r jt.zip /home/jt # H:\ is mounted as /home/jt
>> 
>> It will treat /home/jt above as X:\home\jt, where X is your current
>> drive, and not as H:\.  Hence, it is missing (at least) one call to
>> cygwin_conv_to_win32_path.  But, cygwin_conv_to_win32_path chases
>> symlinks...
>> 
>
>are related to my problem.  Running gdb on itself shows that the /home
>reference doesn't convert properly to the real windows path.  Time for a
>strace.