Cache file location and status questions.

[ko-tengu]

The cache files are placed in %temp%, marked hidden, and never queued to be cleaned up by the game with the current settings and I'm mostly wondering why for all three of these decisions. %temp% gets indexed at system launch so large files kept there for long terms can make Windows less responsive and slower to boot, them being marked hidden makes them very difficult to clean out manually for most users, and the game never deleting the cache or having a button to manually trigger it makes both of these issues worse.

[shiftyscales]

"the game never deleting the cache or having a button to manually trigger it makes both of these issues worse."
This would be covered by #140.

"marked hidden"
Don't know- but AppData itself is already also hidden- getting to that directory in the first place likely wouldn't be done by a user that doesn't already have hidden files shown in File Explorer.

"placed in %temp%"
By their nature- the data that is in this directory is temporary in nature. Presumably this folder should be OS-managed, and it should be deleting temporary files. From what I read- it excludes hidden files- so it's possible that the fact they're hidden was an oversight.

Seeking input from @ProbablePrime or @Frooxius

[Frooxius]

Yes, we plan to add mechanism to clear out the cache, but this hasn't been implemented yet, instead relying on manual clearing.

Marking it hidden was a request from the community, where people were concerned that with it being visible makes it too easy for people to find the cache and potentially rip its contents. We can reverse this, but it does mean that we have two mutually exclusive concerns and we have to pick one of them.

The %temp% location is what it pretty much says - it's the default/standard location for temporary files and majority of apps use this. We're not actually picking this directly either, but using the temporary location provided by the standard API's. I'm not sure why would this location be indexed by default, this sounds more like a (mis)configuration on your system?

[shiftyscales]

I think in this case the lesser of the two evils here would be unhiding the files, and letting the OS manage its temp files as expected. If a user is proficient enough to access things in the cache at all- they probably also already have hidden files visible in the file explorer.

We don't exactly obfuscate the directory of this cache- we have its location well-documented on our wiki, and the user can also specify a custom directory for it if they so choose.

Likewise- for a larger majority of users that wouldn't likely ever even touch the cache themselves- this presumably will allow the OS to handle removal of temp files as needed, and severely lessens the need for us to prioritize #140.

[stiefeljackal]

When Resonite caches an asset from a resdb scheme via download, a variant of the downloaded resdb, or a variant of the imported local asset, it will store a reference to the asset in the Assets table of the local LiteDb. You can allow the OS to handle the cleaning aspect of the cache via removing temp files; however, you will still have the references to these cache file paths within your local LiteDb. If cached files are removed, then references to these cached files should also be removed as well. Otherwise, you will have dead row items in the Assets table of your LiteDb. That is why Resonite will also need to handle cache cleaning as well instead of relying on the OS.

[Frooxius]

We'll definitely need a built-in one to prune the database. Just until that's done, we rely on the external cleaning.

[MrVoltz]

I'm not sure why would this location be indexed by default, this sounds more like a (mis)configuration on your system?

I have encountered this issue before, it delayed login to Windows by tens of seconds. It is caused by the number of files in the directory. I've mitigated it by moving the cache to another folder and using the startup argument.