Overwriteing a script file while it is running....good, bad, indifferent? (1 Viewer)

[JMongi]

Not intentionally I ended up using a script to copy all files in a server location to a local location. One of those files happened to be the same script I was running. The local script file DOES get updated by the "old" script.

Is this due the the script engine quickly reading in the entire script before the actual command queue gets executed?
If so (or something similar), can I use this to my advantage? i.e. I like that I can pull a new version of the launch script with the old version.
But, I realize this is likely too good to be true.

 

[Pat Hartman]

Insanity is my opinion and I'm stickin' to it

 

[The_Doc_Man]

From where were you running the script? On the server or the local workstation?

At least in theory, you can copy a running file to another place and if a copy of it exists in the other place it could be overwritten because that copy isn't active or locked. BUT when a file is actually open for Execute, the running copy cannot normally be overwritten. Has to do with file locking and sometimes with memory locking.

It IS possible, because there IS such a thing as a self-modifying file using binary executing code (and with the targeted memory segment NOT set to "executable code" configuration) - but it is normally not allowed to overwrite a code segment. It is related to Data Execution Prevention and is implemented in hardware, so once set it is impossible for software to easily break. A script doesn't even have the excuse of being binary code that can generate addresses that overlap executable code regions, so that makes it even less likely.

Now a thing that CAN happen is you can overwrite the running script BUT the overwrite doesn't actually take effect until the running code exits. Once the script or executable is active, it will be accessed through its file handle. Do what you want to the directory entries to rename or remove them. The actual file would hang around until it is done.

In fact, that is often why you have to reboot your system after a Windows Update. The old code is still running even though the files are marked for deletion and the directory entries have been updated to select the new code. But you can't switch to using the new code because the executable file is hardware-protected. So when you have a reboot, the new (overwritten) code takes over.

 

[JMongi]

@Pat Hartman -
@The_Doc_Man - I believe the "overwrite doesn't happen until the code exits" is what is going on.

It is a VBScript running locally that will be my DB launch script. So, one thing it does is copy all the files in the production FE directory to the local install directory. It just so happens my DB launch script is located in the local install directory and the server directory. I found this out when changes to the script kept getting undone. I KNEW I fixed that bug, how did it get back in there?!

Then I thought...hmm...this could be good. Now I can update the FE and the launch code (which may go through some iterations to add further checks and such in the future) and the user will pull the new FE and the new launch script and I don't have to change a thing! But, I wanted to make sure I wasn't setting myself up for something unexpected down the road.

 

[The_Doc_Man]

I wanted to make sure I wasn't setting myself up for something unexpected down the road.

Because this "overwrite" action is doing something that Windows guards against, it is possible that a future Windows Update might rear its ugly head. Otherwise, go ahead with what you are doing. Recognize that even if you HAVE made changes in the script that you are downloading, they won't take effect until the next run.

 

[JMongi]

@The_Doc_Man - True. Thankfully it give me time for my neophyte development skills to grow.