cygcheck improvements

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

cygcheck improvements

Christopher Faylor-2
Seeing Igor's analysis of corrupt /etc/services symlinks reminded me
that I wanted to start a discussion on cygcheck improvements.

Ideally, cygcheck should report on things like /etc/services being
wrong.

What other kind of common things could cygcheck be testing for?

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: cygcheck improvements

Dave Korn
Christopher Faylor wrote:
> Seeing Igor's analysis of corrupt /etc/services symlinks reminded me
> that I wanted to start a discussion on cygcheck improvements.
>
> Ideally, cygcheck should report on things like /etc/services being
> wrong.
>
> What other kind of common things could cygcheck be testing for?
>
> cgf


  Cygwin-related entries still pending in the Replace-on-Reboot reg key might
be informative.....


    cheers,
      DaveK
--
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygcheck improvements

Christopher Faylor-2
On Wed, Nov 02, 2005 at 05:37:25PM -0000, Dave Korn wrote:

>Christopher Faylor wrote:
>> Seeing Igor's analysis of corrupt /etc/services symlinks reminded me
>> that I wanted to start a discussion on cygcheck improvements.
>>
>> Ideally, cygcheck should report on things like /etc/services being
>> wrong.
>>
>> What other kind of common things could cygcheck be testing for?
>
>Cygwin-related entries still pending in the Replace-on-Reboot reg key
>might be informative.....

Yep.  Good idea.

Should we run cron_diagnose.sh, too?  Or, more generically, maybe we
should have some way for packages to register themselves with cygcheck
so that cygcheck would know to run them?  That might be a catch-22, though.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygcheck improvements

Christopher Faylor-2
On Wed, Nov 02, 2005 at 12:45:13PM -0500, Christopher Faylor wrote:

>On Wed, Nov 02, 2005 at 05:37:25PM -0000, Dave Korn wrote:
>>Christopher Faylor wrote:
>>> Seeing Igor's analysis of corrupt /etc/services symlinks reminded me
>>> that I wanted to start a discussion on cygcheck improvements.
>>>
>>> Ideally, cygcheck should report on things like /etc/services being
>>> wrong.
>>>
>>> What other kind of common things could cygcheck be testing for?
>>
>>Cygwin-related entries still pending in the Replace-on-Reboot reg key
>>might be informative.....
>
>Yep.  Good idea.
>
>Should we run cron_diagnose.sh, too?  Or, more generically, maybe we
>should have some way for packages to register themselves with cygcheck
>so that cygcheck would know to run them?  That might be a catch-22, though.

Maybe it would be nice to detect things like "ssh installed but not
configured", too.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: cygcheck improvements

Dave Korn
In reply to this post by Christopher Faylor-2
Christopher Faylor wrote:

> On Wed, Nov 02, 2005 at 05:37:25PM -0000, Dave Korn wrote:
>> Christopher Faylor wrote:
>>> Seeing Igor's analysis of corrupt /etc/services symlinks reminded me
>>> that I wanted to start a discussion on cygcheck improvements.
>>>
>>> Ideally, cygcheck should report on things like /etc/services being
>>> wrong.
>>>
>>> What other kind of common things could cygcheck be testing for?
>>
>> Cygwin-related entries still pending in the Replace-on-Reboot reg key
>> might be informative.....
>
> Yep.  Good idea.
>
> Should we run cron_diagnose.sh, too?  Or, more generically, maybe we
> should have some way for packages to register themselves with cygcheck
> so that cygcheck would know to run them?  That might be a catch-22,
> though.
>
> cgf


  Dunno, I think that cron_diagnose is probably a bit overly-specialised to be
run along with every single cygcheck, and in the more general case, if lots of
packages register check-callbacks with cygcheck, we're going to end up
(implicitly) making it dependent on a whole lot of other stuff being there and
working.

  Perhaps if we added it under some kind of --run-extra-tests flag that was
off by default?


  Hey, I had another idea.  It should definitely scan /etc/postinstall and
report any scripts that failed to complete (i.e. don't end with '.done').

    cheers,
      DaveK
--
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: cygcheck improvements

Dave Korn
In reply to this post by Christopher Faylor-2
Christopher Faylor wrote:

> What other kind of common things could cygcheck be testing for?
>
> cgf



  It should search the browser's webcache/history log, and if it doesn't find
that the user's been to view the FAQ lately, it forces it open in a
full-screen window!


    cheers,
      DaveK
--
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: cygcheck improvements

Igor Peshansky
In reply to this post by Dave Korn
On Wed, 2 Nov 2005, Dave Korn wrote:

> Christopher Faylor wrote:
> > On Wed, Nov 02, 2005 at 05:37:25PM -0000, Dave Korn wrote:
> >> Christopher Faylor wrote:
> >>> What other kind of common things could cygcheck be testing for?
>
>   Hey, I had another idea.  It should definitely scan /etc/postinstall
> and report any scripts that failed to complete (i.e. don't end with
> '.done').

Sigh, this would imply that (a) postinstall scripts produce valuable exit
codes (or are run with "set -e", so that they bail out at first sign of
trouble), and that (b) setup doesn't rename scripts that didn't complete
normally to "*.done".  Neither is true at the moment.  PTC, of course.
        Igor
--
                                http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_ [hidden email]
ZZZzz /,`.-'`'    -.  ;-;;,_ [hidden email]
     |,4-  ) )-,_. ,\ (  `'-' Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: cygcheck improvements

Dave Korn
Igor Pechtchanski wrote:

> On Wed, 2 Nov 2005, Dave Korn wrote:
>
>> Christopher Faylor wrote:
>>> On Wed, Nov 02, 2005 at 05:37:25PM -0000, Dave Korn wrote:
>>>> Christopher Faylor wrote:
>>>>> What other kind of common things could cygcheck be testing for?
>>
>>   Hey, I had another idea.  It should definitely scan /etc/postinstall
>> and report any scripts that failed to complete (i.e. don't end with
>> '.done').
>
> Sigh, this would imply that (a) postinstall scripts produce valuable exit
> codes (or are run with "set -e", so that they bail out at first sign of
> trouble), and that (b) setup doesn't rename scripts that didn't complete
> normally to "*.done".  Neither is true at the moment.  PTC, of course.


  Well, only if we wanted it to be 100% infallible.  But my line of thinking
is that cygcheck could do a lot of the basic checks that we normally advise
people to do manually when they present on the list with tricky-to-diagnose
problems.  Just because postinstall scripts don't always report errors
correctly, and just because setup does sometimes rename scripts that didn't
complete, that doesn't stop us from advising people to manually browse through
/etc/postinstall looking for scripts that don't have ".done" on the end.  So
it would be just as useful and likely to save us a cycle of
message-and-response if cygcheck had already provided that information for us.


    cheers,
      DaveK
--
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: cygcheck improvements

Igor Peshansky
On Wed, 2 Nov 2005, Dave Korn wrote:

> Igor Pechtchanski wrote:
> > On Wed, 2 Nov 2005, Dave Korn wrote:
> >
> >> Christopher Faylor wrote:
> >>> On Wed, Nov 02, 2005 at 05:37:25PM -0000, Dave Korn wrote:
> >>>> Christopher Faylor wrote:
> >>>>> What other kind of common things could cygcheck be testing for?
> >>
> >>   Hey, I had another idea.  It should definitely scan /etc/postinstall
> >> and report any scripts that failed to complete (i.e. don't end with
> >> '.done').
> >
> > Sigh, this would imply that (a) postinstall scripts produce valuable exit
> > codes (or are run with "set -e", so that they bail out at first sign of
> > trouble), and that (b) setup doesn't rename scripts that didn't complete
> > normally to "*.done".  Neither is true at the moment.  PTC, of course.
>
>   Well, only if we wanted it to be 100% infallible.  But my line of
> thinking is that cygcheck could do a lot of the basic checks that we
> normally advise people to do manually when they present on the list with
> tricky-to-diagnose problems.  Just because postinstall scripts don't
> always report errors correctly, and just because setup does sometimes
> rename scripts that didn't complete, that doesn't stop us from advising
> people to manually browse through /etc/postinstall looking for scripts
> that don't have ".done" on the end.  So it would be just as useful and
> likely to save us a cycle of message-and-response if cygcheck had
> already provided that information for us.

Fair enough.  I guess what I was saying is that the addition of the two
things I mentioned would make that part of cygcheck output all the more
valuable.  :-)

BTW, one thing that's been suggested a while ago is to have cygcheck
report the user mounts for "SYSTEM" -- that may prevent services from
working properly, and is rather hard to get from the command line (without
getting into the whole sysbash process, that is).
        Igor
--
                                http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_ [hidden email]
ZZZzz /,`.-'`'    -.  ;-;;,_ [hidden email]
     |,4-  ) )-,_. ,\ (  `'-' Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

--jA2IL5H2026974.1130955665/slinky.cs.nyu.edu--

ReSent-Date: Wed, 2 Nov 2005 14:38:12 -0500 (EST)
ReSent-From: Igor Pechtchanski <[hidden email]>
ReSent-To: [hidden email]
ReSent-Subject: RE: cygcheck improvements
ReSent-Message-ID: <[hidden email]>

On Wed, 2 Nov 2005, Dave Korn wrote:

> Igor Pechtchanski wrote:
> > On Wed, 2 Nov 2005, Dave Korn wrote:
> >
> >> Christopher Faylor wrote:
> >>> On Wed, Nov 02, 2005 at 05:37:25PM -0000, Dave Korn wrote:
> >>>> Christopher Faylor wrote:
> >>>>> What other kind of common things could cygcheck be testing for?
> >>
> >>   Hey, I had another idea.  It should definitely scan /etc/postinstall
> >> and report any scripts that failed to complete (i.e. don't end with
> >> '.done').
> >
> > Sigh, this would imply that (a) postinstall scripts produce valuable exit
> > codes (or are run with "set -e", so that they bail out at first sign of
> > trouble), and that (b) setup doesn't rename scripts that didn't complete
> > normally to "*.done".  Neither is true at the moment.  PTC, of course.
>
>   Well, only if we wanted it to be 100% infallible.  But my line of
> thinking is that cygcheck could do a lot of the basic checks that we
> normally advise people to do manually when they present on the list with
> tricky-to-diagnose problems.  Just because postinstall scripts don't
> always report errors correctly, and just because setup does sometimes
> rename scripts that didn't complete, that doesn't stop us from advising
> people to manually browse through /etc/postinstall looking for scripts
> that don't have ".done" on the end.  So it would be just as useful and
> likely to save us a cycle of message-and-response if cygcheck had
> already provided that information for us.

Fair enough.  I guess what I was saying is that the addition of the two
things I mentioned would make that part of cygcheck output all the more
valuable.  :-)

BTW, one thing that's been suggested a while ago is to have cygcheck
report the user mounts for "SYSTEM" -- that may prevent services from
working properly, and is rather hard to get from the command line (without
getting into the whole sysbash process, that is).
        Igor
--
                                http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_ [hidden email]
ZZZzz /,`.-'`'    -.  ;-;;,_ [hidden email]
     |,4-  ) )-,_. ,\ (  `'-' Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

--jA2IL5H2026974.1130955665/slinky.cs.nyu.edu--



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygcheck improvements

Christopher Faylor-2
In reply to this post by Dave Korn
On Wed, Nov 02, 2005 at 05:50:28PM -0000, Dave Korn wrote:

>Christopher Faylor wrote:
>> On Wed, Nov 02, 2005 at 05:37:25PM -0000, Dave Korn wrote:
>>> Christopher Faylor wrote:
>>>> Seeing Igor's analysis of corrupt /etc/services symlinks reminded me
>>>> that I wanted to start a discussion on cygcheck improvements.
>>>>
>>>> Ideally, cygcheck should report on things like /etc/services being
>>>> wrong.
>>>>
>>>> What other kind of common things could cygcheck be testing for?
>>>
>>> Cygwin-related entries still pending in the Replace-on-Reboot reg key
>>> might be informative.....
>>
>> Yep.  Good idea.
>>
>> Should we run cron_diagnose.sh, too?  Or, more generically, maybe we
>> should have some way for packages to register themselves with cygcheck
>> so that cygcheck would know to run them?  That might be a catch-22,
>> though.
>>
>> cgf
>
>
>  Dunno, I think that cron_diagnose is probably a bit overly-specialised to be
>run along with every single cygcheck, and in the more general case, if lots of
>packages register check-callbacks with cygcheck, we're going to end up
>(implicitly) making it dependent on a whole lot of other stuff being there and
>working.

But, if cron is installed, and cron_diagnose fails because of other things not
being available that's useful information, too.  I'm not saying that cygcheck
should stop if cron_diagnose.sh doesn't run.

>  Perhaps if we added it under some kind of --run-extra-tests flag that was
>off by default?

If we have to ask people to do something extra then I don't think there's
a lot of benefit.  If we can ask them to use --run-extra-tests then we can
also ask them to just run cron_diagnose.sh.

Here's a scary one: How about a "cygcheck --report" option which queries
for a "from" email address and sends the report (as an attachment) to
the cygwin mailing list?

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: cygcheck improvements

Dave Korn
In reply to this post by Igor Peshansky
Igor Pechtchanski wrote:

> Fair enough.  I guess what I was saying is that the addition of the two
> things I mentioned would make that part of cygcheck output all the more
> valuable.  :-)

  Oh yes, totally agree!  But that's a slightly longer-term project :)

> BTW, one thing that's been suggested a while ago is to have cygcheck
> report the user mounts for "SYSTEM" -- that may prevent services from
> working properly, and is rather hard to get from the command line (without
> getting into the whole sysbash process, that is).

  While we're at it, it should check the owner/perms on all those
whichever-they-are logfiles that sometimes get owned by the user-id (as a
result of having tested starting up the daemon from the commandline) with
u+a/go-a perms causing services to fail when they later try to run as
SYSTEM.[*]


    cheers,
      DaveK

[*] Heh, or was it the other way round?
--
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygcheck improvements

Christopher Faylor-2
On Wed, Nov 02, 2005 at 06:31:46PM -0000, Dave Korn wrote:

>Igor Pechtchanski wrote:
>
>> Fair enough.  I guess what I was saying is that the addition of the two
>> things I mentioned would make that part of cygcheck output all the more
>> valuable.  :-)
>
>  Oh yes, totally agree!  But that's a slightly longer-term project :)
>
>> BTW, one thing that's been suggested a while ago is to have cygcheck
>> report the user mounts for "SYSTEM" -- that may prevent services from
>> working properly, and is rather hard to get from the command line (without
>> getting into the whole sysbash process, that is).
>
>  While we're at it, it should check the owner/perms on all those
>whichever-they-are logfiles that sometimes get owned by the user-id (as a
>result of having tested starting up the daemon from the commandline) with
>u+a/go-a perms causing services to fail when they later try to run as
>SYSTEM.[*]

How about checking owner/perms of standard utilities and directories?

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygcheck improvements

Brian Dessent
In reply to this post by Christopher Faylor-2
Christopher Faylor wrote:

> What other kind of common things could cygcheck be testing for?

I was thinking that instead of just reporting the current value of
$PATH, it would be handy to also report on the Windows/Registry value of
$PATH.  That way, you can tell if Cygwin is being added to the path in
cygwin.bat or if the person actually added it to their Windows
environment.  I forget exactly why this came up but I remember thinking
it would have been useful more than once when trying to help someone.

I guess it could also explicitly check /etc/passwd and /etc/group, even
though at the moment you can sort of tell if this has been done by
looking at the output of 'id'.

The "pending file replacements" idea is a good one too, as is the
"incomplete postinstall script" idea.  I'm not sure if the "SYSTEM user
has mounts" issue would come up enough to warrant checking for it,
because I can't really think of how that would come to happen.  It might
be good to check if /usr/bin is a user mount and there are services,
then print a warning.  This is something that you can determine by
looking at the output already but having it as an explicit warning makes
it more clear, especially for the user who isn't aware of the problem.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygcheck improvements

Warren Young
In reply to this post by Dave Korn
Dave Korn wrote:
>  if lots of
> packages register check-callbacks with cygcheck, we're going to end up
> (implicitly) making it dependent on a whole lot of other stuff being there and
> working.

You could create a new directory, say /etc/cygcheck[.d].  Any package
that wants cygcheck to run a test for it could put a script in there,
which cygcheck would run.  Then cygcheck doesn't need to have built-in
knowledge of what scripts it should try to run.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygcheck improvements

Christopher Faylor-2
In reply to this post by Brian Dessent
On Wed, Nov 02, 2005 at 12:20:22PM -0800, Brian Dessent wrote:

>Christopher Faylor wrote:
>
>> What other kind of common things could cygcheck be testing for?
>
>I was thinking that instead of just reporting the current value of
>$PATH, it would be handy to also report on the Windows/Registry value of
>$PATH.  That way, you can tell if Cygwin is being added to the path in
>cygwin.bat or if the person actually added it to their Windows
>environment.  I forget exactly why this came up but I remember thinking
>it would have been useful more than once when trying to help someone.
>
>I guess it could also explicitly check /etc/passwd and /etc/group, even
>though at the moment you can sort of tell if this has been done by
>looking at the output of 'id'.
>
>The "pending file replacements" idea is a good one too, as is the
>"incomplete postinstall script" idea.  I'm not sure if the "SYSTEM user
>has mounts" issue would come up enough to warrant checking for it,
>because I can't really think of how that would come to happen.  It might
>be good to check if /usr/bin is a user mount and there are services,
>then print a warning.  This is something that you can determine by
>looking at the output already but having it as an explicit warning makes
>it more clear, especially for the user who isn't aware of the problem.

Given the message that follows this one on the list, should we
be issuing a helpful message if there are network shares and services
being used on the same system, too?

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygcheck improvements

Yitzchak Scott-Thoennes
In reply to this post by Christopher Faylor-2
On Wed, Nov 02, 2005 at 01:23:39PM -0500, Christopher Faylor wrote:
> Here's a scary one: How about a "cygcheck --report" option which queries
> for a "from" email address and sends the report (as an attachment) to
> the cygwin mailing list?

Sounds like a separate program to me.  As flea is to mutt, so
hippo is to cygwin?

Then we could say, cygwin doesn't have bugs, it's got mammals.

Oh, and:

On Thu, Jul 07, 2005 at 08:29:31PM -0700, Yitzchak Scott-Thoennes wrote:
> On Wed, Jul 06, 2005 at 11:27:15AM -0400, Larry Hall wrote:
> > I said "virus program".  That would be something like
> > Norton AV, McAfee VirusScan, etc.
>
> Hmm, is there any way cygcheck could report on intrusive software like
> virus scanners and firewalls?  Though my knowlege on the subject is
> close to nil I think the latter may be doable with WSCEnumProtocols.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygcheck improvements

Corinna Vinschen-2
In reply to this post by Brian Dessent
On Nov  2 12:20, Brian Dessent wrote:
>   I'm not sure if the "SYSTEM user
> has mounts" issue would come up enough to warrant checking for it,
> because I can't really think of how that would come to happen.

I don't think this is really still an issue.  AFAIR, the mounts in the
HKU/S-1-5-18 area were a problem back when user mounts were the default.
Nowadays system mounts are the default and so the creation of SYSTEM
user mounts requires a deliberate action.


Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/