Re: New "feature" introduced with winsup automount?

[Steve Coleman <Steve.Coleman@jhuapl.edu>]

Christopher Faylor wrote:

> I'm not sure why you are installing pthread.dll.  This has nothing
> to do with cygwin.

I stand corrected. I guess I just _assumed_ (and we both know what that
means) that the pthread support would utilize the work from the
sourceware pthreads-win32 project at Cygnus. After all most Unix
environments have to include a separate library to get pthread support
(i.e. -lpthread).

> You deleted a registry entry???  Do you really think that is the
> proscribed way of doing things?

No, in fact I know that this is not the correct way to handle it. I was
just trying to find out 'how it works' on my own without having to study
all the latest source code changes (its all new to me). Often in the
Windows environment the behavior of things like this can be tailored
through the registry, I was just trying to see what it did. Sometimes
when you live on the bleeding edge without documentation you have to
take a little risk. :->

As a designer/developer of a large scale high-performance distributed
processing system, cross platform portability is a big issue for me. In
that respect I am _very_ impressed with the work that Cygnus has done so
far. I guess I just get a little antsy when I see behavior which I don't
see in any of my many Unix environments. My first goal is to understand
why, my second is to learn how to deal with it. I can certainly
appreciate having an alternate way of mapping the drives into
directories as I can see this being very useful in the Windows
environment. It's just that when I cd to a directory and 'pwd.exe',
$cwd, nor '$PWD' agree with where I think I am, I can't help but
wondering what scripts might break. 

For instance, what if a script were used to move a series of directory
structures by the following command:

 "tar - $PWD/$1 | rsh $host tar xvf -" 

where the destination path "$host:/cygdrive/<drive>/<path>/$1" does not
exist but "$host:/<path>/$1" did, and it was mounted from a different
drive or even on a Unix system? 

Yes I agree, this one is an easy fix, but it is also completely
preventable. If the default behavior was to map $PWD ($cwd, $HOME, etc.)
to /<path> rather than the /cygdrive/x/<path> syntax, then we would not
have to rewrite any scripts. The alternate syntax would of course be
available for accessing things outside of the normal directory tree. 

Q:Might this mapping also affect automated remote distribution programs
like rsync and ftp as well?

> >a2dslc:/c/Gnu/home/coleman:% ls -al //D/
> >ls: //D/: No such file or directory
> 
> Ah.  Well, this probably explains things.  You're not using the latest
> snapshot.  You're apparently using a snapshot from a week or so ago.

Behind? Probably, it took me about a week (part time) to build the whole
tree. There were a lot of  header files (or links to them) that did not
seem to make it into the i686-pc-cygwin32 directory tree structure. I
had to keep restarting the build after each minor correction. Now that
I've done it once I'll try to keep it up to date. ;-)

Please keep up the good work!

Thanks.

-- 
Steve Coleman     <Steve.Coleman@jhuapl.edu>   http://www.jhuapl.edu/
<<--------->> Johns Hopkins Applied Physics Laboratory <<---------->>
Balt:443-778-6330 Fax:443-778-5597 Wash:240-228-6330 Fax:240-228-5597