A file editing itself

[Uten]

Or you could do somthing like this:

regedit /E c:\autoit.reg "HKEY_CURRENT_USER\SOFTWARE\Autoit v3"

And then you have all the backup software out there

[Azu]

What's that do exactly? Just back up the HKEY_CURRENT_USER\SOFTWARE\Autoit v3 key?

[Uten]

Spot on. You won't get it done faster than that

[dandymcgee]

Or you could do somthing like this:

CODE

regedit /E c:\autoit.reg "HKEY_CURRENT_USER\SOFTWARE\Autoit v3"

And then you have all the backup software out there rolleyes.gif

What's the point in backing up just autoit's reg keys? If anything ever happened to my computer reinstalling autoit takes ten seconds. I'd be more worried about the "AutoIt Scripts" folder on my desktop than anything else, lol. What a dumb comment...

[Uten]

@dandymcgee: If you dont have any more imagination than that why bother at all?

[dandymcgee]

@dandymcgee: dry.gif If you dont have any more imagination than that why bother at all?

Sorry, I don't get what exactly you meant by just backing up AutoIt reg keys and nothing else. I simply asked how to back up registry, and your way didn't work for what I wanted (Complete Backup). Thank you Azu for explaining it short and sweet. I hadn't realized the export function. I know you were just kidding Uten, but I really was asking a serisous question. No harm done. Edited September 19, 2006 by dandymcgee

[Uten]

regedit /E c:\Currentuser.reg "HKEY_CURRENT_USER"
regedit /E c:\Classes.reg "HKEY_CLASSES_ROOT"
regedit /E c:\LocalMachine.reg "HKEY_LOCAL_MACHINE"
regedit /E c:\Classes.reg "HKEY_USERS"
regedit /E c:\CurrentConfig.reg "HKEY_CURRENT_CONFIG"

Obviously if your entire registry is gone you wont get the result you want with this and you want get it wit the manual export option in regedit.

The you also have ntbackup.exe (it's part of XP I belive)

Pleas remember that the thread is about a selfmodifying file. And someone pointed out that the file might get corrupted. My hidden point was that data can get corrupted anywhere it is stored. So you might come to the point where you need a backup.

[Valik]

Uten, you have a valid point that data can get corrupted anywhere. But IMO, getting corrupt data should not corrupt the entire program, too. If something in the registry or a file on disk gets corrupted, that's fine. Delete the offending files/keys and start over. If the data gets corrupted and it's stored inside the executable, then what? That copy of the executable is forever permanently destroyed. If you accidentally re-distribute that executable - it's still broke. If you back it up - it's still broke. The entire program becomes broken because there is no way to remove tainted data because it's stored where nobody can get to it. The only fix is to delete the executable and re-install the product - a step that would not be necessary if the program used a more conventional method for saving data.

[Uten]

I see your point Valik. Data and executable seperation it is a strategy that has proven itself over time.

When it comes to the backup thing it It's like the chicken and egg problem. What came first corruption or a valid backup.

Separating data and executable has proven a better approach in most circumstances. I have a case her at my desk where the program is broken but the data available. We also have the case of access databases where the runtime is outside and script code is inside the selfmodifying file (*.mdb).

All I suggest is taking backups of your work where ever it is (hmm, not that I'm particularly good at that my self)..

Reading the first post again I know how simple it is to achieve what Azu asked for with AutoIt. The backup thing, and separation, is just good advice.

EDIT: Clarified a sentence (I hope).

Edited September 20, 2006 by Uten

[Azu]

Uh...

Just make a backup of the one, single, self contained file.

If anything goes wrong, all you need to restore is that one file, which will have everything in it.

I'm not sure how having the settings stored separately (this having two files that could be corrupted, and two files that need backed up) is more convenient or safe then having it all in one.

[strate]

Can you copy a running executable? If so you might be able to do that right before it edits itself. Then if you are able to script for a known corruption, you can decide which backup to use.

[Confuzzled]

Aren't smart Operating Systems starting to separate the executable and data memory spaces? Good luck in bypassing that!

[JaySquared]

Well, one way to do a file editing itself is to open/read the original source code. Do the string manipulations to edit/update the code then have the macro recompile the sourcecode with a different name. Run the new program and exit. I thought this was an interesting concept so I'm working on a "personal assistant" program that will have this capability. If the program itself get's corrupted, all I will need to do is basically backtrack thru the self compiled versions and find the corruption.