Hello, so to update,all I need to do is run "curl -O https://gitlab.com/cscs/maclean/-/raw/main/maclean' again?
Probably. Or you get it from the AUR.
Yes if you have gotten it manually then you can just delete the current one and download again.
As mentioned above there is also the AUR package which will receive upgrades more normally.
Thanks for this tool bro, but is it just me or is the tool painfully slow? Like âClean thumbnail and $HOME cache of files not modified for 2 weeksâ seems to take a very long time.
Those 2 steps are now somewhat slower than desired for checking modified time of files when noatime mount options is detected.
It has to then traverse that entire directory and find each file and check those modification times and then feed the ones older than 2 weeks back to the array to be deleted. This can take some time on large cache folders that have not had this (or similar) operation performed on that path any time recently.
Those prompts also do not exist if no such files are found so in those cases the operation is skipped.
So for example I just ran it now and the home cache steps only took a few seconds to complete. I then ran it again and had no home cache prompts at all.
I still would like to speed up those mtime operations though and can hopefully make some gains by the next release.
I see. So what am I supposed to do if I want to remove unused $HOME cache older than 2 weeks? Am I supposed to wait for a long time? Or is there a faster way?
I would just say to wait - it should still complete even if it takes 90 seconds.
And again it may be highlighted that in the case of noatime that the only way to check for age like that is modification or mtime. Or I suppose creation time but that is yet again a little different.
When I ran it for the first time a few days ago it took well over 10 mins, which can be frustrating for a first time user, wondering âhey, did this process hang or something?â
But now that I know to expect it, itâs no big deal. Itâs not like itâs stopping you from doing anything else while it runs.
Thanks for the comments.
Ouch though - 10 Minutes is a decent while.
I have a few thoughts;
- Add a mini rotating character thing so its obvious it is working.
- I think this can more be blamed on the increased safety checks around rm - there are dozens of lines making sure that nothing important gets deleted by being a weird symlink or similar and each path gets checked individually - I might make multiple âworkersâ to iterate over âchunksâ of the paths asynchronously.
The second one is already mostly implemented and I am testing it out locally.
The first one is easy enough (I use a few variants of it in some other scripts so I can just do the same things here) but I consider it low priority and have still not committed to the idea here. Maybe if we can reclaim enough speed it will revert to not being so desirable to have a sort of âloading animationâ.
I would say having some feedback that the process didnât crash for some reason is always a good thing even if things are quick. I know the updater I use has something like that for KDE widget checking and despite being 20s at most, is still good feedback to let the user know âhey, Iâm still doing the thingâ.
I have implemented a loading/spinner thingy as well as (hopefully) significantly improved the speed especially around those initial home cache functions.
It is not yet merged into main, and likely will not for at least a few days, but the eager may still get it early from the dev branch;
If you do test it out please let me know if there are any issues!
I believe it is in a safe/workable state, yet of course an âits betaâ caveat still applies.
Cheers. 
Hi! 
Nice to see further development on this really useful tool!
Thx for that! 
One question/suggestion from my side: Is it possible to enhance this tool with the ability to wipe the Octopi-Cache too? Because the âOctopi CacheCleanerâ always finds a lot of stuff even when running immediately after Maclean.
Hello,
If I am not mistaken octopi does not have its own cache.
pacman does.
And maybe your aur-helper.
Both of which are accounted for .. but in the case of the regular (pacman) package cache it specifically only removes uninstalled packages and, for installed packages, removes all but the 2 last versions (paccache -rvk2).
This is intentional to retain the ability to downgrade locally.
Maybe therein lies the difference - in the case of the cache clean initiated through octopi you are choosing to keep less.
As of earlier today version 0.3 has been released. 
This should contain some of the previously discussed features like both quicker home cache functions and loading animations for all operations so that the user knows there is activity.
Users who got the script manually can download it from source again and users of the AUR package should have gotten the update automatically (possibly depending on aur-helper configuration).
I hope this treats everyone well.
And as always constructive feedback is welcome.
Looks good to me. Maybe an idea for v0.4: print a little âwelcome messageâ including the version number before doing the work. Something like
maclean v0.x
Clean thumbnail cache of files not modified for 2 weeks (y/N)?
etcâŚ
Edit: with âlooks good to meâ I mean âworks for meâ. I admit that I canât really read bash script code, so I canât judge the code quality. But I trust @cscs very much, otherwise Iâd never run a script which goes that deep into my system and âdoes thingsâ 
Maybe -y ( Assume yes to all prompts (non-interactive) ) would be better instead of -a, since it can be combined with all other parameters (or alone).
In the previous version I tested, the user could run e.g. maclean -ja, which is effectively the same as maclean -a. This is confusing and potentially dangerous because -ja looks like it enables two separate options, while in reality it silently behaves the same as -a.
Please check the diff of the -y implementation: 9851bc7
Thanks.
I am a little conflicted between keeping the output more constrained/minimal and applying something like this.
Maybe a bannery thing that can be hidden with a flag? 
..
Hm.
Some good points for consideration.
Though while I cannot fully evaluate the diff/patch just now I am not sure it does enough to implement y as a âyes to any range of options (default all)â as I believe to be intended.
( Also, if you could, the gitlab source would of course be preferred for sharing/inspecting/applying changes in the way of PRs. Though its alright if that is not feasible for some reason. )
PS.
Also updated the tabe in the opening post here to match current project/operations.