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