This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add FAQ 4.46. How do I fix find_fast_cwd warnings?


On 2017-11-12 16:02, Ken Brown wrote:
> On 11/12/2017 4:27 PM, Brian Inglis wrote:
>> +    <para>Some ancient Cygwin releases asked users to report problems that were
>> +      difficult to diagnose to the mailing list with the message:</para>
>> +
>> +    <screen>find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please
>> report
>> +    this problem to the public mailing listcygwin@cygwin.com</screen>
>> +
>> +    <para>These problems were fixed long ago in updated Cygwin releases.</para>
> 
> The wording of the warning message was changed 3 years ago, in commit 0793492. 
> I'm not sure that qualifies as ancient.  I also don't think it's accurate to
> refer to the problem as "difficult to diagnose" or to say that the problems
> "were fixed long ago".

The original message was added in 2011 - 1.7.10 maybe earlier - NT4 support was
dropped around then - pretty ancient in Cygwin terms of how many Windows
releases have had support dropped since then!

> The issue (Corinna will correct me if I'm wrong) is simply that new releases of
> Windows sometimes require changes in how Cygwin finds the fast_cwd pointer.  So
> users of old versions of Cygwin on new versions of Windows might have problems,
> and this can certainly happen again in the future.  But the FAQ doesn't need to
> go into that.  Why not just say what the warning currently says (see
> path.cc:find_fast_cwd()):
> 
> "This typically occurs if you're using an older Cygwin version on a newer
> Windows.  Please update to the latest available Cygwin version from
> https://cygwin.com/. ; If the problem persists, please see
> https://cygwin.com/problems.html.";
> 
> You can also add your sentence about contacting the vendor who provided the old
> Cygwin release.

We are trying in the FAQ entry to persuade an annoyed user that it may be in
their best interest to do some remediation, rather than just complain in an
email to an org they think is a company (cygwin.com) they have never heard of,
who they expect from their application message to take care of their problem
with no other effort on their part, and who they can blame if nothing happens.

Assuming they find the FAQ entry, emphatic language may persuade them to do
something more than the message says they should do.

First time anyone has mentioned the updated error message - I just hashed
together some emphatic comments folks on the list have made in response to
posts, to get things started.

Messages like "Couldn't compute FAST_CWD pointer" do not tell users what has
gone wrong in terms they can understand, indicate if it is something they might
be able to work around, or whether they can not do anything and should report a
problem, and how to do so usefully.

It would probably be best if such messages provided only a simplified
explanation like "Cygwin could not find how to get your current directory in
this Windows release" with a simple FAQ entry URI e.g.
...#current-directory-not-found for elaboration, and in this case maybe we could
just use the slow RtlGetCurrentDirectory_U routine.

We are getting little information on what apps these users are installing and
from where, that drop a Cygwin instance on their systems, with maybe no
information on how to upgrade, whether they are commercial products, or
abandonware downloaded from e.g. SourceForge.
Perhaps we should also be asking for some of these questions to be answered in
the FAQ entry.

Could we perhaps persuade the sourceware admins to add an email filter to
auto-reply with a link to the FAQ to any original FAST_CWD messages from
non-subscribers and also send the reply to the list to show it has done so?

I think we also need a FAQ entry advising developers on the best approach to
incorporate Cygwin Setup into their install and upgrade processes.
Should we recommend they develop their own packages using cygport and provide
their own local or remote mirror as in https://cygwin.com/package-server.html?
Is there an easy way to let their users pick an official mirror and add their
own mirror as in the section on "Creating an overlay Cygwin package server"?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]