develooper Front page | perl.makemaker | Postings from January 2006

replacing "inuse" Win files (was Re: Help with a build error)

Thread Previous | Thread Next
Linda W
January 26, 2006 02:51
replacing "inuse" Win files (was Re: Help with a build error)
Message ID:
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 ->, copy the new
file into place, then setup a pending delete in the registry
with a simple command line util like ""'s
"movefile" that queues up pending file operations to take
place upon reboot, i.e.: 'movefile ""' 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> ""
 # 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.


demerphq wrote:

>On 12/5/05, Randy W. Sims <> 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
>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
>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'
>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.
>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/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About