Move Arial Cache Folder to Application Support?

[gregarios]

Suggestion:
To avoid problems that a myriad of tools (including the MacOS during some point upgrades) that purge the cache regularly, please move the default location of the Arial (cache) folder to /Library/Application Support like most other programs.
This folder never gets purged by anything, and is home to many programs' registration info, preferences, cache data, and other stuff just like Arial needs.

[glouel]

Interesting ! I’m still unclear about changes in 10.15 but that could be a great idea indeed. I really need to understand what they are doing with caches right now, it’s so weird. Thanks for the idea in any case will come back to it for next version !

Edit : Side note, I ended up upgrading my old MBA from High Sierra to Mojave (...), and cache wasn't destroyed during that update. I really think I should address that because it took me by surprise and will other people.

[glouel]

Well, I'm finally starting to understand what they did, under 10.15, screen savers are now sandboxed and can't access much (if anything) outside of a container. So, in my case, I can successfully access the containerized user cache directory, but it's not ~/Library/Caches/Aerial but ~/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver/Data/Library/Caches/Aerial !

/Library/Caches looks unaccessible for us now, as I would suspect /Library/Application Support (user one should work fine).

Because a screensaver is a plugin and not an app (we are now run by a system app called legacyScreenSaver), we can't even ask for entitlements such as accessing the filesystem so it looks like we'll have to live in the container from now on. This may break other things such as location, but it's too early to tell wit the nib bug. What a (completely undocumented) mess !

[glouel]

So I'll be closing this one since containerization changed everything !

[glouel]

Actually I'm reopening this one (should not close an issue before coffee). I'm unsure how cache cleaning and containers work (I'd love any info on that), so user's Application Support may still be the superior choice for path, in the container ! I'm a bit afraid that container data, as a whole, may be considered as wipeable on OS upgrades anyway but who knows.

[glouel]

Hey @gregarios

So, after much thoughts here's my master plan, assuming we have no other choice than living in a container.

Next beta (maybe tonight/tomorrow) :

• Aerial will create an Aerial dir in ~/Library/Application Support/ (or it's containairized version which is ~/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver/Data/Library/Application Support, really rolls off the tongue !)
• this appSupport path will NOT be user changeable.
• Aerial.log, and the JSONs will go there
• Any download will go there (let's say only on Catalina+)
• Cache path is still a thing, is still user changeable BUT if you are on Catalina, there are severe restrictions (we have read only access to local disk, I'm unsure if that includes network drives and usb drives yet, let's hope so) so when looking for videos in it's cache, Aerial will look both in appSupport directory AND cacheDirectory to see if a video file exists.
• I'm leaving the default cacheDirectory for new users to ~/Library/Caches/Aerial for now to try to avoid changing too many things at once

At some point in the future:

• default cacheDirectory for new users will be appSupport (still user changeable to whatever, with same caveat as noted above)

Having some sort of dual cache path structure will help people who don't want to store all videos in the container (understandable) and using appSupport will be safer in the long run.

[glouel]

At some point in the future:

• default cacheDirectory for new users will be appSupport (still user changeable to whatever, with same caveat as noted above)

Future is now by the way, this is the default in latest betas ;) If you reset to default, it will now point to user's application support (whether the normal one or the sandboxed one depending on macOS version).

[glouel]

Closing with the release of 1.6.0 finale.