Edge case: mismatch between the lockfile and the existing filename of the given mod
meza opened this issue · 3 comments
Happens when an existing lockfile is used with a mods folder that contains manually imported files.
Sometimes the manually imported files won't be the exact files that are in the lockfile. This would result in the update/install downloading a different version of the same mod, leaving the dangling file there.
A possible solution could be to run a check for files and run a scan (without lookup). Marry them up and then do a proper lookup on the extraneous files.
This issue exists with:
- SCAN: when there is a version of the mod present but it's not a version that's in the lockfile
- INSTALL: it will install the version in the lockfile, ignoring the fact that there's an older version of the mod in the mods folder
- UPDATE: ^ same as the install but the update runs the install first so if the install works fine, it should be fixed
We could run a PRUNE as a nuke option but I think having a proper solution would be much more future proof.
All in all, we need the concept of "managed but not the correct version" as a first class citizen.
So this issue is a very deep issue but a valid one. I've found a solution that bridges the gap of the missing capability but isn't as streamlined as I would expect it.
I will use this "temporary" solution for the time being as it gets the job done and prevents bad impressions of the system.
I will however need to revisit the entire topic at a later date.
For future Meza:
Every operation should verify that the lockfile only contains mods that are in the config.
Every operation should evaluate the files in the mods directory.
A file could be:
- fully managed (appears in the config and the lockfile)
- partially managed (appears in the config but NOT in the lockfile)
- mismatched (appears in the config but the lockfile hash differs)
- not managed (does not appear in the config or the lockfile)
The list of mod files in the mod directory will have to come as a list with either one of the statuses above and every operation should deal with them accordingly.
The INSTALL (and consequently the UPDATE) action should remove the file in error and use whatever is in the lockfile
The SCAN action should ask what to do
The LIST action should show these statuses too
With these changes, the SCAN functionality might get redundant or change in responsibility.
🎉 This issue has been resolved in version 1.2.1-next.6 🎉
The release is available on GitHub release
Your semantic-release bot 📦🚀
🎉 This issue has been resolved in version 1.2.1 🎉
The release is available on GitHub release
Your semantic-release bot 📦🚀