You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that cache exclusion is hardcoded we can't even add it via filters with:
+/var/cache/pacman/pkg/*
Or to be precise, we can add that filter but it doesn't work.
This simply breaks the complete backup and deceives a user.
App issues and app regressions happen frequently on cutting edge, rolling release distros so having a copy of installed, previous versions of apps is incredibly important. While the need to use timeshift to roll back to older snapshots arises rather rarely (once a year at most when you know what you are doing), rolling back apps is needed more often.
The problem is, we may not detect the app issue right away and clean the cache. In such a case, I was reaching for my backup drive, looked for the older snapshots and then I had my older package file there. Simple solutions. This was a reason to use timeshift - it produces backups that are in an accessible format that I can use to cherry-pick files if needed.
For git packages (from AUR) it's even more important because we don't get multiple versions in pacman cache. The new version simply OVERWRITES the old one. So the only place where we can find the older install file is THE BACKUP.
I used timeshift snapshots to find older install packages many times in the past. Now, when I needed it again and found an empty directory, timeshift let me down and simply fooled me by claiming it backups completely the root directory:
/root/**
This should mean something, but currently, it isn't so I consider it a bug.
The mentioned commit should at most provide some default filter to exclude package managers cache so we could decide whether we want/need it or not so we could change it, but it just completely took that from the possibilities. So if there was a need to filter out the cache directory one could always set it manually. Once this is hardcoded and forced upon us silently, it was like the proverbial throwing the baby out with the bathwater. Now nobody has a choice and timeshift doesn't do what it shows is doing.
With newer timeshift versions we weren't even informed about that change so I expected cache files to be there and they weren't so timeshift fooled me. How many users will find out that the important files they thought to be backed up are not there?
I had to ask someone to send me timeshift 19.01 install file to be able to downgrade it. I also had to add it to the ignore list. That is currently the only way to have a fully functional timeshift.
Please, reverse the mentioned commit back and if needed add package managers cache exclusion in a clear, unobfuscated way so they users could decide about it. Forcing silently this solution is a serious regression that breaks the functionality of timeshift, because it doesn't do full system backups.
The original topic where I realized about the problem was discussed here:
This issue was original documented on the teejee2008 repository (original issue). Since it's still relevant, I'm am copying it over to here.
The issue stems from this:
teejee2008/timeshift#437
Now that cache exclusion is hardcoded we can't even add it via filters with:
+/var/cache/pacman/pkg/*
Or to be precise, we can add that filter but it doesn't work.
This simply breaks the complete backup and deceives a user.
App issues and app regressions happen frequently on cutting edge, rolling release distros so having a copy of installed, previous versions of apps is incredibly important. While the need to use timeshift to roll back to older snapshots arises rather rarely (once a year at most when you know what you are doing), rolling back apps is needed more often.
The problem is, we may not detect the app issue right away and clean the cache. In such a case, I was reaching for my backup drive, looked for the older snapshots and then I had my older package file there. Simple solutions. This was a reason to use timeshift - it produces backups that are in an accessible format that I can use to cherry-pick files if needed.
For git packages (from AUR) it's even more important because we don't get multiple versions in pacman cache. The new version simply OVERWRITES the old one. So the only place where we can find the older install file is THE BACKUP.
I used timeshift snapshots to find older install packages many times in the past. Now, when I needed it again and found an empty directory, timeshift let me down and simply fooled me by claiming it backups completely the root directory:
This should mean something, but currently, it isn't so I consider it a bug.
The mentioned commit should at most provide some default filter to exclude package managers cache so we could decide whether we want/need it or not so we could change it, but it just completely took that from the possibilities. So if there was a need to filter out the cache directory one could always set it manually. Once this is hardcoded and forced upon us silently, it was like the proverbial throwing the baby out with the bathwater. Now nobody has a choice and timeshift doesn't do what it shows is doing.
With newer timeshift versions we weren't even informed about that change so I expected cache files to be there and they weren't so timeshift fooled me. How many users will find out that the important files they thought to be backed up are not there?
I had to ask someone to send me timeshift 19.01 install file to be able to downgrade it. I also had to add it to the ignore list. That is currently the only way to have a fully functional timeshift.
Please, reverse the mentioned commit back and if needed add package managers cache exclusion in a clear, unobfuscated way so they users could decide about it. Forcing silently this solution is a serious regression that breaks the functionality of timeshift, because it doesn't do full system backups.
The original topic where I realized about the problem was discussed here:
https://forum.manjaro.org/t/timeshift-empty-var-cache-pacman-pkg/105940
Thank you
The text was updated successfully, but these errors were encountered: