Cached textures don't update when a texture is updated

[LGhassen]

Describe your problem with KSPCF :

Once png textures in GameData are compressed and cached by KSPCF, if textures are modified externally, KSPCF doesn't detect this and old versions of the textures are loaded from cache. Is it possible to fix this perhaps by adding a checksum check or a last modified date check?

KSP version : 1.12.5 Link to your KSP.log file : Sorry don't have one

[gotmachine]

A checksum check would more than negate the perf gains, but KSPCF does check the file creation date and should invalidate the cache for changed png files.

Unfortunately, this isn't 100% reliable due the file system caching behaviors. I didn't find a workaround back then, but maybe I didn't dig deep enough.

On NTFS volumes, overwriting a file doesn't always update creation time immediately. From what I remember, the cached time is invalidated immediately only if the new creation time is more than one hour different, otherwise it will update at the next cache invalidation, which can take a while to happen. I don't know what happens on other file systems, but there is likely some similar caveats.

Back when I wrote the patch, I did some limited testing (on a NTFS drive) by switching between different versions of some mods both with CKAN and manually and the cache was properly invalidated, so this being an issue for end users should be quite rare.

However, cache invalidation failing might happen quite frequently in the context of mod development, when you frequently update textures at short time intervals, I guess this is what is happening for you ? For mod development, I suggest disabling the texture cache altogether.

[LGhassen]

Thansk for the detailed reply, this is indeed what happened to me during mod development and now I see it happening to more and more other developers who are iterating on cloud textures. No worries though I'll just put up a notice saying to disable it when developing.

[gotmachine]

After checking a bit, turns out that KSPCF only relying on creation time is insufficient on Windows, it should also check last modification time. I didn't use it because behavior isn't well defined on OSX/Linux, but this can be solved by just taking the max value out of the two.

Additionally, I added a check to compare png file size, which is more reliable as far as file systems are concerned (there is no caching behavior like for creation/modification dates), and while it isn't guaranteed to change between two versions of a png file, the probability is still high so it's an additional failsafe.

[LGhassen]

Thanks a lot @gotmachine, this is great!