Re: Extend faq.using to discuss fork failures

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Aug 19 12:21, Christopher Faylor wrote:
> On Fri, Aug 19, 2011 at 06:13:22PM +0200, Corinna Vinschen wrote:
> >On Aug 19 12:01, Ryan Johnson wrote:
> >> BTW, I hope that rebasing wouldn't require every invocation of
> >> setup.exe to shut down all cygwin processes... I really like how
> >> right now I can pull new packages some configure script needs,
> >> without having to shut down 4-5 sessions of emacs.
> >
> >Seriously, you could propose a patch to rebase, which leaves blocked
> >DLLs alone and only tries to rebase the colliding ones, if any.  Plus a
> >patch to rebaseall to add a flag
> >"--don't-test-for-ash-only-just-ignore-what-you-can't-change".  Well, a
> >single char option might be better...
> >
> >The rebase sources are available by CVS:
> >
> >  $ cvs -d "pserver:anoncvs@sourceware.org:/cvs/cygwin-apps co rebase
> >
> >Send patches to the cygwin-apps list.
> 
> As I mentioned in cygwin-apps, I think a --backup option of some kind
> would be useful so you could restore to a previous state.
> 
> Why won't anyone implement my idea????????????????!!!!!!!!!!!!

I still don't see how this would be useful.  I see occasionally
situations in which rebase *seems* to have broken a DLL.  Or, to put it
more carefully, some DLL was suddenly broken, without being able to lay
a finger on the actual cause.  However, reverting the DLL base address
to the former state never worked as a fix for me.  Only reinstalling the
DLL worked, and a subsequent rebasing did not break the DLL.  So, to
repeat myself, I don't see how a reverse or backup mode would be useful.


Corinna

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