> -----Original Message-----
> From: Gary R. Van Sickle [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, March 16, 2002 4:14 PM
> PAIN! WINDOWS... DRIVERS! FILE... SYSTEM... AHAAAAAHHHHHHHHHHHH!!!
>
> Actually I was thinking this would be a perfect job for that
> snazzy new daemon coming down the pike; queue the file in
> question up with the daemon, and have the daemon wait until
> nobody's looking (i.e. nothing's using the
> file-to-be-replaced), and then swap the new one in. The
> daemon could replace itself in a somewhat similar manner; the
> new daemon would send the old daemon a signal to shut down
> and then replace it with itself when Windows eventually let go of it.
Yeah... I've actually written proof-of-concept code for setup.exe to do
just that. (Imagine setup.exe self-updating and living in /usr/bin.)
However there are a number of things that make me go urgh with this.
1) new-foo exports symbol bar that is needed by the post-install script.
When should the script run?
(This is an issue today btw).
2) new-foo exports symbol bar that is needed by other userland app. How
do we tell the user that they can't run that app until all programs have
been shut down?
3) It's similar to the file-delete-queue hack in cygwin, and whilst that
is quite successful, it's not seamless.
I'd rather be _real_ simple about it. I.e. Offer a choice: reboot after
the install or close app foo now. The user does one or the other, not a
hybrid (close app foo after the install).
Of course, a patch to do it will be treated very differently to ideas
:}.
Rob
--
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/
