Closed nekohayo closed 3 weeks ago
:thinking: any idea on what would be the best way to do this? Checking if the folder exists is not really resource intense but at the same time having it run every time the app starts or closes is excessive :/ running it once and then saving a bool in gsettings so it doesn't run again seems nice, but having to do gsettings lookups might be equally as intense (which is not much) :shrug:
Short of listing the parent directory and reusing that for both folders (if that's even a thing), or having this cleanup code in place only "for a couple of releases", or cheating by doing this "only if launched on day 1 of the month" (which is bound to happen eventually :P) I don't intuitively see a perfectly efficient way to do this, but at the same time I think the 1 disk access for the check on startup is unlikely to be a notable performance impact :)
only if launched on day 1 of the month
But then we have to deal with datetime performance :skull: there's no winning here, I'll just check on shutdown and remove the code on the next minor :p
Describe the bug
As can be observed in the screenshot in issue #1089, users who have been running Tuba for a long time may have a leftover cache from when it was a newborn fork of Tootle. That duplicate cache folder should be removed automatically as a convenience.
Steps To Reproduce
Logs and/or Screenshots
Instance Backend
Mastodon
Operating System
Fedora 40
Package
Flatpak
Troubleshooting information
os: GNOME 46 (Flatpak runtime) prefix: /app flatpak: true version: 0.8.2 (production) gtk: 4.14.4 (4.14.4) libadwaita: 1.5.3 (1.5.1) libsoup: 3.4.4 (3.4.4) libgtksourceview: 5.12.1 (5.12.0)
Additional Context
In my case,
~/.var/app/dev.geopjr.Tuba/cache/dev.geopjr.Tuba/files.mastodon.social
has 1 JPEG and 85 mp4 files, all from 2023
~/.var/app/dev.geopjr.Tuba/cache/tuba/manual/media
has 1 JPEG and 84 mp4 files, all from 2024 (there are no other files/subdirs than "media" in manual")