Files created after the installation of a mod can cause problems during upgrades

[Ippo343]

If a mod creates one or more files after it has been installed, these would not be removed during an uninstall and thus won't be removed between upgrades.

This can cause problems: in fact, ferram4 has anticipated me that it will cause problems for "anyone coming from pre-0.14.5 to the most recent versions." This upgrade requires the mod folder to be completely wiped, and the current version of ckan will not do that.

We need to sort this out ASAP: I suggest that we prioritize the implementation of preserved files and make a complete wiping of the mod's folder not only the files, as the default behaviour.

[KriPet]

Maybe add a metadata spec of paths to be removed on delete. Could be useful if some mods have special requirements

[pjf]

We need to sort this out ASAP: I suggest that we prioritize the implementation of preserved files and make a complete wiping of the mod's folder not only the files, as the default behaviour.

We can't do that. Lots of mods put things into (say) the Toolbar folder, or sneak their config into the RemoteTech folder, or have a whole bunch of mods installed into UmbraSpaceIndustries. Plus players may add their own files for whatever reason. Deleting files that we know nothing about would be terrible.

There are two good ways of solving this:

• Mods which create files ship with empty versions of those files. This means we'll cheerfully remove them when the mod is removed or uninstalled.
• We update the spec to say that the mod will create additional files, even though they're not in the zipfile itself.

From a robustness standpoint, the first may be superior; not only will things work correctly using the existing CKAN client (or at least cause a file conflict if trying to upgrade from an older install), but anyone doing a manual install who doesn't delete the whole folder first will at least overwrite the files needed.

Long term, the second is going to help us solve many edge-cases, and from an architecture standpoint isn't that hard to implement. We simply add the file to the registry, even though it's not physically present on the system.

Relates to #15 (preserved files) Relates to #327 (health checks, including unregistered files)

[KriPet]

A problem with the first one (empty files) is that the filenames might be createt dynamically, so you don't know them in advance.

I'd suggest updating the spec somehow. Maybe specifying globs/paths for deletion.

[Ippo343]

Okay, new idea: we might add a flag in the spec (or even an uninstall stanza of some sort) which will cause ckan to delete every file in the mod's folder if and only if it is not owned by any other mod. This would preserve the files added by other mods and also delete files that have been created dynamically.

Or, other option: make the directory wiping conditional with a --purge option that can also be activated by default in the mod's metadata using an uninstall stanza of some sort.

[vosechu]

Would it be possible to treat this like Git does and keep a manifest of the files that were downloaded, where they should be located, and the sha of the file so that we can tell if they have been modified? I suspect this just shifts all the burden onto the GUI though and doesn't actually fix anything.

At least then we would know whether files had been modified and we could assert which ones were safe to delete.

[politas]

I think a --purge option with associated GUI controls as Ippo343 mentioned is the answer, so users can choose to get rid of a mod's added files. For any mod, there are times you want to purge, and times you don't.