FVerbaas posted at 7:56PM Wed, 18 March 2020 - #4383927

Begins to look like a sort of vaulting. A database with the files extracted, from which product it was extracted, and which files call which resources, so you know what you can delete and what to keep. Calling files can have direct path.

You are right. I had the same idea, as I started to script a delete-function.

One of the problems: The script, while unpacking a ZIP, may: rename files, store them in other places, change content, skip extracting them, etc. A simple and useful "delete" function isn't possible.

For me it seams easier to have a central "database" knowing what is going on.

Right now I prefer the following idea:

First installation of a package: Parsing the package, adjusting (or removing) paths, correcting versions, and more. The (possibly corrected) pathnames/filenames are moved into the database (under the package-name). The original package goes into the backup, the modified package into the backstore.

Workspace installation: The database is used to determine which files are required for a complete installation and these are installed in the workspace.If files already exist in a different directory, the Poser files are adjusted during the installation (but only for the files that are in the database).

Each database entry that refers to a file also holds a counter that is incremented for each installation. If different packages point to the same file, that file will not be removed from the workspace until the last package pointing to it is removed.

Also important:

1. A function to turn an installed package into a ZIP file to be installed normally.
2. A function to update a package in the database (include newly created or changed files/directories).

At the end the question: Where do I take the time to realize all this? Besides everything else I already have in work.

Translated with www.DeepL.com/Translator (free version)

---