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

Re: replacing "inuse" Win files (was Re: Help with a Cwd.pm builderror)

Thread Previous | Thread Next
From:
Randy W. Sims
Date:
January 29, 2006 20:31
Subject:
Re: replacing "inuse" Win files (was Re: Help with a Cwd.pm builderror)
Message ID:
43DD968D.8030206@thepierianspring.org
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.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About