Separate cache dir from Maxima data dir

[p0358]

So that it doesn't put these files into people's backups.

There were cache, temp and downloads sub-dirs previously, all ephemeral. I've put contents of first two directly into ~/.cache/maxima and the last one still as sub-dir.

I'm only unsure about download_queue.json, but it feels like it'd be better off also being in cache (if someone wiped cache during a download, it might not necessarily be safe to assume whatever download was going can be just resumed like that, because maybe they just restored their system from a backup after re-setting it up again, maybe game dirs are gone too, etc.)

Technically downloader and its queue could go into a state dir, but I think that would be overkill at that point, so let's keep things simple.

As for Windows, data_dir() is {FOLDERID_RoamingAppData}\_project_path_\data, while cache_dir() is {FOLDERID_LocalAppData}\_project_path_\cache. Well, I guess Origin/EA App do separate their files between these two in a similar fashion, I recall they were putting cached avatars into %LocalAppData% too...

[wannkunstbeikor]

Do we want this to be in cache and not in the temp directory?

[p0358]

I'm not sure about /tmp, since it's usually tmpfs so only tiny files can be put there; also might be more hassle:

Since /tmp/ is accessible to other users of the system, it is essential that files and subdirectories under this directory are only created with mkstemp(3), mkdtemp(3), and similar calls. For more details, see Using /tmp/ and /var/tmp/ Safely.

I'm not sure how big this particular folder is during downloads though, I see it has .eazstate files after it was finished at least. Might want to make Maxima wipe them after the download is finished regardless, while /tmp should be wiped on reboot (it will be if tmpfs), some people have really long uptime too... So removing them once they're not needed is the correct choice.

But if it's just these tiny files and you don't mind a third function like maxima_temp_dir(), then sure could do that (then we could put them in Windows's %TEMP% aka %APPDATA%\Local\Temp)

[headassbtw]

i would keep in mind that cfg(unix) applies to macOS as well, under which ~/Library/Caches would be the right path

not a huge deal as we don't officially support macOS yet, but i'd avoid stacking up future issues for that when the rest of the codebase is fairly friendly on it

[p0358]

Very fair point actually, but I'm seeing this applies to current maxima_dir() too, where it seems on macOS it's probably supposed to use ~/Library/Application Support instead of ~/.local/share.

In fact, in this case, it seems that our library would apply the exact same logic and outcome on Linux as well:

• https://docs.rs/directories/latest/directories/struct.ProjectDirs.html#method.data_dir
• https://docs.rs/directories/latest/directories/struct.ProjectDirs.html#method.cache_dir

That means the easiest solution will be to just drop the Unix variant and rely on the ProjectDirs. And I guess I'll add some unit tests for that, since I wouldn't feel that comfortable just leaving it like that without some direct documentation what the paths are expected to be.

[headassbtw]

see previous comment, but LGTM otherwise. sorry for the delay on reviewing, i've been slammed at work

[p0358]

No worries, been slammed too. I don't have a setup on Windows, so would appreciate if someone could run the unit test on Windows just to be sure too:

cargo test -- --nocapture

running 4 tests
[test_maxima_cache_dir] Expected: "/home/p0358/.cache/maxima" Got: "/home/p0358/.cache/maxima"
[test_maxima_dir] Expected: "/home/p0358/.local/share/maxima" Got: "/home/p0358/.local/share/maxima"
test util::native::tests::test_maxima_cache_dir ... ok
test util::native::tests::test_maxima_dir ... ok

No paths should have changed in Windows at all, and on Linux between my first and second commit, but always better safe than sorry.