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

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

Thread Previous | Thread Next
From:
demerphq
Date:
January 30, 2006 03:16
Subject:
Re: replacing "inuse" Win files (was Re: Help with a Cwd.pm build error)
Message ID:
9b18b3110601300145k5774e5d3n45a1f1834e1d12c0@mail.gmail.com
On 1/30/06, Randy W. Sims <ml-perl@thepierianspring.org> wrote:
> 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.

We dont need this behaviour as we arent going to be dealing with any
DLL's that will be started prior to perl starting. Move at boot
behaviour is only required for dlls that are loaded at boot. Since the
files we care about are only locked because of Perl we only need close
perl.

> > 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.

This needs more investigation. It has to be tested using native win32
builds and not cygwin. At the very least Cygwin and native perl use
different default permission masks when opening files. Also be wary of
cygwin pretending its deleted a file when it has in fact turned on the
delete on close flag of the opened file, theres nothing to stop
another process from turning it back off afterwards.

> 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?

I think it sounds interesting, but its occured to me that maybe a
better approach is to conceive of a way to prevent the files from
being locked in the first place.

I was thinking that Dynaloader could be changed to copy all DLL's that
it loads to some working tree before loading them under certain
circumstances.  Maybe this way the problem can be solved in backwards
compatible way by bundling a special dynload overload or something.
And of course this would only be required to be used for win32 builds.

Anyway, more ideas, no solution as yet. :-)

yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"

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