Mail Archives: cygwin/2006/12/25/10:20:52
Larry Hall (Cygwin) wrote:
> What the file is named is insignificant. When the file is already in
> use,
> you will run into the situation where the newly installed file is not
> moved
> into place for use immediately .
---
That is current cygwin behavior. It isn't required to be that way
on NT.
> Renaming the old file to something else
> won't help this situation, since the original is still in use.
---
It would seem to solve the original poster's problem of the new files
getting installed with ".new" suffixes and having to reboot to cure the
problem.
Any new processes will use the newly installed library -- not the original.
The original, as on Unix, will remain in-use only by processes that
already have
the old library open. On unix, if you delete an in-use library, running
programs still have a "handle" to the old library and continue using it
until
they exit. Usually this isn't a problem.
The process is simple - one moves the "old" name to a "tmpname" and schedule
it for deletion at next reboot (though it may be removable before then,
deleting it at reboot is usually acceptable). After you have renamed
the old library to a "tempname" (or the tmp dir), you move the new library
into the target location with the correct name.
The important aspect is that user's don't have to reboot to install new
versions of files. The old files are cleaned up at next reboot which can
come "anytime", since the user's new files are already installed and ready
for use. Any new programs that start will use the new library -- just as
happens on Unix.
> Before the
> new one can affectively be used, all references to the old one must be
> terminated.
----
No more so than on Unix. Any old processes will continue to use the
old library until they exit -- the same as on Unix. Any new processes
will start using the new library immediately -- just as on Unix. No
one requires Unix to be rebooted every time a library is replaced.
In-use libraries under NT can be replaced just as they can be under Unix.
> The new one can then be safely moved into place. The general
> limitation of not being able to replace an in-use DLL with a new one is a
> Windows limitation, not a Cygwin one.
----
It hasn't been a Windows limitation since Windows 2000. It's
not a limitation in NT. Maybe this was true on pre-NT (Win98/ME)
Windows?
However, on NT, it's no more a limitation than it is on *nix.
> The situation is generally handled
> by rebooting. It's a common Windows paradigm. :-(
---
It's also one that significantly decreased in being a problem with
the advent of WinXP (though it was true in Win2000, AFAIK). As previously
mentioned, perl on Win32 had the same problem. They fixed
it to allow cpan replacing "inuse" libraries without requiring a reboot.
The key is that under NT, executable code in DLL's locks a region on
disk by disk number and block/sector range -- not by any lock on the
name. A rename doesn't affect the content of the old library -- thus it
can be done, effectively moving the old library out of the way of
further use and allowing the installation and use of new libraries
immediately by new programs without reboot.
The only "caveat" is like the one on Unix: any active processes will
continue to use the old library until those processes are reloaded.
That's not usually an issue.
It certainly makes cygwin updates easier to not have to reboot. It's
been years since cygwin forced me into a reboot -- I just look at the
pending moves with pendmoves(sysinternals) and do the move, that
cygwin doesn't, manually. I usually move the old libraries to /tmp,
as it will get cleared out automatically by maintenance
processes -- even if a reboot doesn't happen.
If you need any more explanation of how to implement this, lemme know,
but it's pretty straightforward:
mv mylib.dll .mylib.dll.old-001 (target must be unique)
mv newlib.dll mylib.dll (and set permissions)
(then add .mylib.dll.old-001 to the pend-rename queue to
schedule deletion)
-linda
--
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/
- Raw text -