Re: How to get started
- To: debian-win32@lists.debian.org
- Subject: Re: How to get started
- From: Arend Lammertink <alam@home.nl>
- Date: Tue, 02 Dec 2003 10:59:25 +0100
- Message-id: <3FCC627D.2020403@home.nl>
- Reply-to: alam@home.nl
- In-reply-to: <1070242586.1112.29.camel@localhost>
- References: <20031128162950.35458.qmail@web21601.mail.yahoo.com> <87fzg62rcd.wl@netfort.gr.jp> <3FCA13B5.7080603@users.sourceforge.net> <8765h14lgs.wl@netfort.gr.jp> <5A6A6A46-239A-11D8-9875-000A95EB7FDC@umich.edu> <1070242586.1112.29.camel@localhost>
Robert Collins wrote:
On Mon, 2003-12-01 at 12:04, Satadru Pramanik wrote:
Windows has been moving further and further away from a paradigm of
requiring reboots to replace files. Whatever glue is written to get
around the problem of not being able to replace in use files, please
consider the use of functionality such as qchain in windows, which lets
you schedule several reboot requiring updates for just one reboot
cycle.
*cough*.
Microsoft have got better at dynamically unloading and reloading
modules, thus working around the issue...but the underlying problem -
that a open file/directory cannot be replaced
hasn't changed at all.
I've done some googleing and it looks like it is possible to rename a
file that's in use (from the command-line). Of course, there's no way to
find out if this works _all_ the time, but according to
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=9486169wnr%40ttelmah.demon.co.uk
it should work:
"In article: <36344dc7.0@195.1.61.6> frode.gill@agresso.no (Frode
Gill) writes:
>
> In article <390103591wnr@ttelmah.demon.co.uk>,
Roger@ttelmah.demon.co.uk wrote:
> >> How can I copy a dll file to the system32 directory if the file is
> >> being used by Windows?
> >
> >The normal 'proceedure' is:-
> >rename the.dll the.old
> ^^^^^^
>
> And this is not possible when the .dll is in use by windows...
>
> Another way of doing it, is to put the new <file>.dll in the directory
> as <file>.tmp, and have it renamed to .dll during startup. There is a
> way to set this in the registry - not sure how to do it though :-/
Since when?. You can rename a DLL in use, you just cannot move it.
This is the proceedure used by most standard 'updates' (including
those from MS). You _must_ have administrator priviledges. The code
'using' the DLL will carry on happily using the 'renamed' one, until
you re-boot."
If he's correct that MS also uses this method, it shouldn't be too
difficult to just rename the file inuse and delete it later if it's not
in use anymore.
There's also some articles:
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q184/4/08.ASP&NoWebContent=1
http://support.microsoft.com/default.aspx?scid=kb;EN-US;228930
http://www.microsoft.com/technet/archive/default.asp?url=/technet/archive/columns/inside/6-7-99.asp
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q181/3/45.asp&NoWebContent=1
According to these articles there are two utilities that might be used
to replace system files that are in use: inuse.exe and mv.exe. (It seems
that inuse.exe is newer.)
These make use of a registry key that can be delay file operations until
the next reboot: "this executable actually does an edit to the registry
to perform a "PendingFileRenameOperations" on the next reboot."
So, the simplest strategy would be something like:
================
void replaceFile( const char* src, const char* dest )
{
const char* destOld = getOldFilename(dest); // Unique filename
if ( rename( dest, destOld )
{
copy(src,dest);
if ( !inuse(destOld) )
remove(destOld);
else
scheduleForRemoval(destOld);
return;
}
cerr << "WARNING: could not rename " << dest;
cerr << ". Replacement of " << dest;
cerr << " is delayed until reboot." << endl;
const char* tempfilenm = getTempfileName(dest);
copy( src, tempfilenm );
scheduleReplacement(dest,tempfilenm);
}
====================
We can use the "PendingFileRenameOperations" registry key both for
deleting the old files and for replacing those files that couldn't be
renamed in case there would be files that couldn't be renamed.
-- Arend --
Reply to: