[DUG] Renaming file in use

[Jeremy Coulter]

I wonder, based on this, that because I am doing WinExec()  that this may be
part of my problem on Win98/NT4. I shall have to test ShellExec() on Monday.

Jeremy 

-----Original Message-----
From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz] On
Behalf Of Kyley Harris
Sent: 3 December 2005 00:23
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Renaming file in use

That is a working example.

ShellExecute works fine. It is not posting a message. ShellExecute will not
return until the new process is spawned. Also, I am passing 0 as the first
param. Clearly this is a basic example, and if your application uses mutexes
or any other behaviour to prevent it running 2 times, then this would not
work very well unless you removed the mutex.

Halt is also not necessarily the killing technique of choice.
Depending on how much you care, Application.Terminate is a cleaner way of
doing it. But then who knows what may then keep running to prevent the new
copy loading properly. I would generally never run this in a form or button
for such reasons, but put all this code in a routine called directly before
application.initialize, and then halt without launching any of the normal
windows management that TApplication does.


FOLLOWING IS A MORE REALISTIC EXAMPLE. Except in my real life i'd generally
be connecting to an update server via tcp and downloading an update on the
fly and saving it to ParamStr(0) after doing the rename.
but putting a file there is easier.

to test this, just pick any other program and copy it to the folder and call
it new.exe you will find that it works seamlessly. ( PS. if not WinXP then
DONT WASTE TIME TESTING! Why?  
Because I dont sell software to win98 )

program PTest;

uses
   Forms,
   sysutils,
   windows,
   shellapi,
   utest in 'utest.pas' {Form1};

{$R *.res}

begin

   if FileExists(ExtractFilePath(Paramstr(0))+'new.exe') then
   if RenameFile(ParamStr(0),ChangeFileExt(paramStr(0),'.bak')) then
   begin
     CopyFile(PChar(ExtractFilePath(Paramstr(0))+'new.exe'),pchar(
ParamStr(0)),true);
     ShellExecute(0,'open',pchar(ParamStr(0)),'','',sw_show);
     Halt;
   end;

   Application.Initialize;
   Application.CreateForm(TForm1, Form1);
   Application.Run;
end.




On Sat, 03 Dec 2005 00:09:33 +1300, Ross Levis <ross at stationplaylist.com>
wrote:

> Are you sure you can run a ShellExecute just before terminating the 
> program?  I've tried that and found the ShellExecute didn't run unless 
> I put a sleep for half a second or so before terminating the program.  
> I though perhaps the message was still to get to processed before the 
> app terminated, and the app terminating killed the message, or 
> something or that.
>
> Ross.
>
> ----- Original Message -----
> From: "Kyley Harris" <kyleyharris at gmail.com>
> To: "NZ Borland Developers Group - Delphi List" <delphi at ns3.123.co.nz>
> Sent: Friday, December 02, 2005 11:08 PM
> Subject: Re: [DUG] Renaming file in use
>
>
> Like it or hate it..
>
>    if RenameFile(ParamStr(0),ChangeFileExt(paramStr(0),'.bak')) then
>    begin
>      CopyFile(PChar(ExtractFilePath(Paramstr(0))+'new.exe'),pchar(
> ParamStr(0)),true);
>      ShellExecute(0,'open',pchar(ParamStr(0)),'','',sw_show);
>      Halt;
>    end;
>
> This is a valid method of updating an application under windows, and 
> is a design feature.
>
> I completely dispute the fact that this helps viruses.
>
> If a virus wants to replace ditto.exe, with ditto.exe (which is now a
> virus) its certainly doesn't need
> to sneak around and rename a file. If the virus is there, then its 
> going to do a kill process/or a copyfile.
> if they want to takeover a dll that is in use, typically they would 
> bind them selves in as a startup process to override the dll's etc 
> before those dll's are used. Windows XP automatically kills any dlls 
> and replaces them if they are system dlls for just such a virus 
> prevention, so no real concern there either.
>
> It doesn't need to worry about renaming something????  besides that.
> Viruses hijack processes by binding themselves in as stubs on the 
> application which still runs the normal code so that you don't find 
> out...
> if they
> renamed a file to replace it with something else you would find out 
> very quickly when the job is not getting done anymore....
>
> On Fri, 02 Dec 2005 18:28:48 +1300, Rohit Gupta <r.gupta at xtra.co.nz>
> wrote:
>
>> Sean,
>>
>> I thought I would try this out and you are right, another crappo from 
>> Microsoft.  Not only can you rename the file, it also renames the 
>> path in the shortcut that launched it.  Another way a virus can get in.
>> And
>> you can even rename the dll thats in use.  Further to that if you 
>> rename a system dll, it silently copies it from the backup.  All test 
>> on win2k.  Will all this really work the same way on XP, 2kserver, 
>> 2k3server, Terminal Services, a pc using Domain Server and Longhorn 
>> ????
>>
>> I would still maintain that its is idotic to rely on this mechanism.
>> Any
>> primitive virus protection thingy should foil this.  But does it ?
>> :-(
>> Zonealarm certainly did not complain.
>>
>> I despair.  Its worth the effort to write a virus to teach MS a 
>> lesson.
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
>
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi



--
Kyley Harris
+64-21-671821
_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.10/190 - Release Date: 01/12/2005
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.10/190 - Release Date: 01/12/2005