Linda W wrote:
Having gone through this operation a few times today (replacing
inuse files). I discovered a fairly easy way that should work
on "NT" based versions of Windows (don't know about Win9x).
Windows (XP tested) allows *renaming* of inuse files. According
to the way Win-NT manages memory, it ties paging activity to
a specific file on disk by using (device,sector#,# of sectors).
Thus anything that might free up or change those sectors is
disallowed, but a file-rename operation is safe for currently
mapped "DLL's".
Thus, one could rename Cwd.dll -> .oldCwd.foo, copy the new
file into place, then setup a pending delete in the registry
with a simple command line util like "sysinternals.com"'s
"movefile" that queues up pending file operations to take
place upon reboot, i.e.: 'movefile .oldCWD.foo ""' will delete
the named file next reboot.
In short, when copying a file "src" to a target path,
before copying the file, check to see if an existing target
needs to be moved out of the way first:
if [ -f "$target"]; then
mv <tpath>/<tname> <tpath>/<tmpname>
# can try to delete it first...
rm -f <tpath>/<tmpname> || movefile <tpath>/<tmpname> ""
fi
# then copy
cp <source> <tpath+file> || "fail"
I haven't had a chance to look into it, but if this works, this looks
like possibly the best solution to me, even if it doesn't work on the
nearly antiquated Win9x/ME series.
Originally, I had narrowly conceived of this as a problem only for
Module::Build, but as pointed out, it seems to affect any client of
ExtUtils::Install. So, I agree with Yves that it should be fixed as much
as possible inside EU::Install. Who owns it now? Schwern had talked
about breaking it out:
MakeMaker Changelog:
6.30_01 Tue Aug 16 23:53:27 PDT 2005
* ExtUtils::Command, ExtUtils::Install, ExtUtils::Manifest,
ExtUtils::Mkbootstrap, ExtUtils::Mksymlists and ExtUtils::Packlist
are all now considered to be separate distributions. To avoid a
circular dependency, MakeMaker distributes its own versions but CPAN
should not index them and they will not overwrite a newer, installed
version.
I think some of those modules may already have a new maintainer, but I
can't remember which or who, and I can't find references.
Yves, this would change things somewhat from your recommendation. EU::I
would copy the old files to new names, copy in the new files, and return
a list of files that need to be deleted??? I don't believe it should
return a list of failures; rather, I think it should not be allowed to
fail--it should be able to do a complete rollback if anything fails and
then throw an exception if that doesn't break compatability.
Some details still unclear, but I like this better than the unload
library, replace, & reload method because it avoids the possiblity of
loading a new version of a dynamic library that is mismatched with the
already loaded front-end perl module. And reloading the pm file, while
possible, is just as problematic for the same reasons.
Is this sensible?
Randy.
