Re: //c - Ouch!

["Larry Hall (RFK Partners, Inc)" <lhall at rfk dot com>]

At 12:32 PM 9/26/2001, Keith Starsmeare wrote:
> > I'm not suggesting that your idea is bad.  Indeed, it certainly does have
> > merits.  However, like you, I wouldn't know where to put this so that it
> > would address the need.
>
>How difficult would it be to add a warning into setup? I must download that
>code someday!!


Shouldn't be too bad for someone who understands C/C++ code.  If you're
interested in pursuing this, perhaps you want to consider providing some
generic facility to apprise users of important changes as part of the 
installation.  If this appeals to you, you may want to check the email 
archives.  There has been one discussion, started with a somewhat 
tongue-and-cheek remark (of mine) that generated allot of discussion and 
some good ideas along this line.        


> > Also, I will say that I don't recall a single query on this list since
> > the change that has indicated this is a major problem.  Everyone seems
> > to be taking it in stride.
>
>I'm worried that people won't realise why cygwin's suddenly going so slowly,
>and they're too shy to post, or just not interested in joining the mail
>list, and so they just plod on until they finally discover that //c no
>longer means what it used to mean!


It's hard for me to believe in a silent majority after being on this list
for a while but that's just my cynicism creeping in again! ;-)  I'd be
surprised to find out that someone who notices poor performance in Cygwin
doesn't report it to this list, especially if they compare it to the 
performance in a DOS prompt.  But this is all hypothetical so it doesn't
mean much.  However it seems to me that the concern you're voicing here
is that of using "//" in paths.  The old //<drive> notation is only a 
very small piece of that.  Perhaps another mechanism or message is needed 
to combat this general issue, since it's not related to this particular 
release.  People need to be made aware that "//" in Cygwin is the same as 
"\\" in Windows environments.  Both invoke UNC semantics, which implies 
network support, which implies overhead.  If people learn this, then they 
will understand why using "//" in paths is a bad idea, regardless of 
whether it used to be supported syntax for drive access or not.  But I 
wouldn't recommend tackling this issue with some addition to setup.exe.
Such a notice would need to be part of *every* release.  So maybe any
notice you might want to add to setup for 1.3.4/5 would simply note that 
old //<drive> notation isn't supported and this is now equivalent to a UNC
path, with the pointer to the appropriate document to explain UNC.  Well,
I expect I'm getting a little ahead of you! ;-)  If you want to pursue 
this and need further input from me, just ask (though I turn into a 
pumpkin at the end of the week for 3 weeks so the window is narrow! ;-) )


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/