WeiDU 200 will not be downgrade happy, ...suggest your fix! Options

[The Bigg]

I've modified the backup system in WeiDU 200, to allow backups of multiple files with the same base name (previously, if you held a backup of E.G. override/baldur.gam and Save/path/baldur.gam, only the former would be restored, resulting in potential problems). Unfortunately, I haven't seen a way to have the system be 100% compatible in case somebody wants to downgrade his WeiDU version (more on the technicalities later). Since I know that some modders on this board insist on using WeiDU 185 and suggesting people to downgrade their versions, I hope to collect ideas on how to fix the situation without stirring excessive trouble.

The only way to cause problems is if user installs a mod using WeiDU >=200 and then uninstalls it using WeiDU < 200. Mixing the versions is always safe during install, and uninstalling a <200 mod using a >=200 mod is safe.

These are the ways to solve the situation I can see:

• I do some further homework and recode this to allow safe mixage. Pro: modders won't have to do a thing, the best of both worlds. Con: I need to think a way to implement this.
  Obviously, this'd be the best idea if I can do this.
• I drop the idea altogether. Pro: modders won't have to do a thing. Con: my personal pride
• I develop a special version of WeiDU 185 that doesn't cause problems. Pro: easy for users, and modders will still be safe from bad ideas. Con: if you have a personal grudge against me, this is not a solution.
• I write a program to make backups 185-compatible. Pro: might be easier to accept for people who dislike me. Con: hard for users.
• Modders not requiring WeiDU 185 for their installs. Pro: users won't have to worry about complicate downgrade routines. Con: if you have a grudge against me, this is obviously not a solution.

Now, the algorithms (PM if you want to read the code), in case you want to brainstorm a better backup algorithm:

WeiDU <200:

{BACKUP}/UNINSTALL.X contains the list of modified files.
When copying override/sw1h01.itm: add "override/sw1h01.itm" to UNINSTALL.X, copy old override/sw1h01.itm (if existing) to {BACKUP}/sw1h01.itm.
When copying temp/sw1h01.itm: add "temp/sw1h01.itm" to UNINSTALL.X, don't keep a backup because {BACKUP}/sw1h01.itm already exists.

When restoring:
read override/sw1h01.itm in UNINSTALL.X, delete override/sw1h01.itm, move {BACKUP}/sw1h01.itm to override.
read temp/sw1h01.itm in UNINSTALL.X, delete temp/sw1h01.itm and do not restore the copy (which wasn't saved).

WeiDU >=200:

{BACKUP}/UNINSTALL_NEW.X contains the list of modified files.
When copying override/sw1h01.itm: add "override/sw1h01.itm" to UNINSTALL_NEW.X, copy old override/sw1h01.itm (if existing) to {BACKUP}/override.sw1h01.itm.
When copying temp/sw1h01.itm: add "temp/sw1h01.itm" to UNINSTALL_NEW.X, copy old temp/sw1h01.itm (if existing) to {BACKUP}/temp.sw1h01.itm.

When restoring:
read override/sw1h01.itm in UNINSTALL_NEW.X, delete override/sw1h01.itm, move {BACKUP}/override.sw1h01.itm to override.
read temp/sw1h01.itm in UNINSTALL_NEW.X, delete temp/sw1h01.itm and move {BACKUP}/temp.sw1h01.itm to temp.

If you can see a way to edit the WeiDU >=200 algorithm so that the WeiDU <200 restoring algorithm still works, this'd be really helpful.

[plainab]

WeiDU >=200:

{BACKUP}/UNINSTALL_NEW.X contains the list of modified files.
When copying override/sw1h01.itm: add "override/sw1h01.itm" to UNINSTALL_NEW.X, copy old override/sw1h01.itm (if existing) to {BACKUP}/override.sw1h01.itm.
When copying temp/sw1h01.itm: add "temp/sw1h01.itm" to UNINSTALL_NEW.X, copy old temp/sw1h01.itm (if existing) to {BACKUP}/temp.sw1h01.itm.

When restoring:
read override/sw1h01.itm in UNINSTALL_NEW.X, delete override/sw1h01.itm, move {BACKUP}/override.sw1h01.itm to override.
read temp/sw1h01.itm in UNINSTALL_NEW.X, delete temp/sw1h01.itm and move {BACKUP}/temp.sw1h01.itm to temp.

If you can see a way to edit the WeiDU >=200 algorithm so that the WeiDU <200 restoring algorithm still works, this'd be really helpful.

I'm not a programmer, but maybe you can follow my idea and see if it is implementable.
Somehow read the file and save it's relative location to the weidu exe file. So that when the mod in question is uninstalled it will repair modified files in their original relative location.

Example modifying a save file:
COPY ~save/000000-Game_Save/baldur.gam~ ~save/000000-Game_Save~
DOWHATEVERPATCHES
BUT_ONLY_IF_IT_CHANGES

Weidu will save {BACKUP}/{PATH}baldur.gam
When mod is uninstalled weidu would replace {BACKUP}/{PATH}baldur.gam where in this example save/000000-Game_Save/ = {PATH}

I know that the path information is already gathered by weidu as SOURCE_DIRECTORY so why can't that information be applied to weidu's backup and restoration methods

By default the path variable would be empty. During uninstall Weidu 200 would look for the saved path info and if it's not found would uninstall with the 199 and less method because {backup}/{path}file.ext with an empty path variable is the same as {backup}/file.ext.

I think I'm clear as mud, but once again I'm not really a programmer (at least not by trade or education).

[The Bigg]

I know that the path information is already gathered by weidu as SOURCE_DIRECTORY so why can't that information be applied to weidu's backup and restoration methods

Because <200 doesn't do this, and I can't alter the <200 algorithm.

I can try to mix the two systems and use `basename x` for the first file x, and `echo x | sed -e's,/\\\\,,g'` for further files named x. This could cause breakage in really obscure situations, though. But then, I believe this was going to cause breakage even when doing a clear <200 install/<200 uninstall, so this'd be a moot point.

I can't say offhand, so I'll have to hack a bit and test various cases to see if this causes anything to act differently - but then, I'm sure that the given situation isn't going to happen, unless for mods using destructive biffing techniques, and it is probably possible that even then I can tiptoe around troubles and avoid differences. Will tell more later today or tomorrow.

EDIT: the dir1/file.ext and dir2/file.ext situation was causing breakage in WeiDU <200 (basically, installing and uninstalling a mod in the given situation would move a file and remove the others) and is difficult to reproduce without ad-hoc code, so I'm going to ignore eventual troubles in the downgrade path in this situation (which, I stress, is not going to happen, save for ad hoc code). Downgrade-happiness for "sane" mods is going to be granted, of course.

This post has been edited by The Bigg: Jul 15 2007, 08:44 PM