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"
See chapter 7: Memory Management in "Windows Internals" by
Russovitch and Solomon (p457 in 4th ed.) for info on how
the memory manager map executable sections to pagefile or
memory-mapped files.
Linda
demerphq wrote:
On 12/5/05, Randy W. Sims <[EMAIL PROTECTED]> wrote:
demerphq wrote:
(Regarding the problem of perl based installers not being able to
install on WIn32 any file that the perl process itself has open
during the build process. Such as .dll's and modules with unclosed
__END__ or __DATA__ sections.)
Ill see what I can do as time permits. But id like to see this problem
fixed too so ill try to make some time.
Thanks for talking through these issues and any other help you may be
able to offer.
Ive started looking into this issue again because of
http://use.perl.org/comments.pl?sid=30312&cid=45812
I have MB 0.27_04 patched so that it creates a batch file from the
Build script, one which is deletable via realclean.
I started looking into handling the installation issue but it looks
like this requires changes to ExtUtils::Install.
I also contemplated how this issue would impact CPAN.
Currently im thining the following:
1. E::I::install() doesnt bother to check to see if the copy command
was successful.
2. For win32 (and maybe everything) install() should keep a list of
files that failed copy.
3. install() should return the list of failures
4. M::B or EU::MM need to be able to capture this failure and on win32
translate it into a batch file containing the copy commands.
5. CPAN(PLUS)? needs to be able to receive feedback from the install
framework (either) that the install failed, in which case it needs to
terminate and launch the batch file.
6. The batchfile should be smart enough that it relaunches the
CPAN(PLUS) enviornment.
The idea i have currently for M::B is that when install fails it
writes a batchfile called
Build_followup.ext
(Substitute .exe for either .bat on pre NT machines or .cmd on NT machines).
The build_followup.ext would do the copies using standard Win32 copy
commands. It would then relaunch the Build script, but with a flag
that indicates "Post followup". The post followup action would verify
that the copy was successful and then delete the build_followup.exe
file.
Where things get tricky is when you are using CPAN(PLUS) to do this.
How does the install framework inform CPAN(PLUS) that the install can
only happen once CPAN has terminated? And how would CPAN(PLUS) restart
properly? IE, what happens if it is installing as part of the 'follow'
behaviour?
Anyway, even if CPAN(PLUS) is not updated, at least M::B could be used
as EU::MM can be used, that is outside of CPAN to correctly install a
file that CPAN or MB might have locked.
Also, something that would be really useful would be a way to force
perl to close all files. Ie, to unload all dll's, close any intenral
filehandles kept open for __DATA__ and __END__ etc. Then this batch
file malarky would be totally unnecessary.
Cheers,
yves
ps: I have patches but they are fairly minimal at this point. Id
prefer to send them through once they are a bit more comprehensive.
--
perl -Mre=debug -e "/just|another|perl|hacker/"
