-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Sonarr uninstall not removing 'appdata' when erasing all data files #5450
Comments
As a comparison, the uninstall logs for other *arr apps do include the removal of the 'appdata' folder:
Unlike these, the |
hey @Safihre, I don't know if this is something you can help with. I've looked at the code but I don't really understand why it isn't behaving like the other *arr apps with similar code. |
Not sure.. I don't think we even control that, DSM does that removal. I thought. Or am I wrong? @hgy59 |
From what I see in the code, the removal of the 'appdata' content happens when this function is called: spksrc/mk/spksrc.service.installer.dsm7 Line 178 in 1b66ba6
This function seems to be a shared one across multiple packages. The main difference I see is that compared to Lidarr and Radarr, the line Removing files... is not written to the log. This line gets called following this conditional statement within the above function:spksrc/mk/spksrc.service.installer.dsm7 Lines 183 to 184 in 1b66ba6
However, the variable wizard_delete_data seems to be set externally when the uninstall function is called in DSM as shown in this section of code:spksrc/mk/wizard/uninstall_uifile Lines 11 to 13 in 1b66ba6
As such, to my knowledge, once the user selects Erase all of the package data files. (Not Recoverable) , then the variable should be set true and the conditional statement triggered. This does not seem to be happening in Sonarr but I can't understand why.
Hopefully one of you more experienced with the codebase can validate my analysis and hopefully identify something I missed to address this issue. |
I suggest this behaviour depends on the fact, that the |
Is there anybody willing to get the hands dirty and create a sonarr update package that migrates the package name from |
Thanks for the feedback. I'm having trouble reconciling this from the code though. If we look at the uninstall log samples I provided above we have these segments: Radarr
Lidarr
But if we look at Sonarr the following is seen in its log:
Notice that the step for 'postuninst' does seem to get called but the conditional statement which triggers the I am all for changing the internal package name for Sonarr but I don't see how exactly it relates to this issue. |
Your right, it has nothing to do with this internal package name (and I doubt whether it is worth to change this). just uninstalled lidarr and got some errors in /var/log/packages/lidarr.log
Then a new installation und uninstall of the new lidarr package (20221114-10) had no such issues. I will check with sonarr... |
The sonarr package was built before the merge of #4807 that contains "Fix uninstall wizard (remove hidden files as well)" so only nzbdrone.log is deleted and the hidden folders not (.config, .mono). and the former version did not log the deleted files... |
Thanks much for getting to the bottom of this. I've tested it by installing a package built from #5471 and then uninstalling it. Based on the below log it cleared out the files completely when requested to do so:
Based on the above, this issue will be automatically closed once #5471 is merged. I note that you proposed a number of amendments to make the PR more complete. Thanks again for your analysis of this issue. EDIT: A solution to this issue is also included in #5511. |
Is this a new Bug?
Package Name
Sonarr
Package Version
20210717-19
Device Model
DS916+
Device Architecture
x86_64
Firmware Version
DSM 7.1.1-42962 Update 1
What happened?
When uninstalling Sonarr and selecting
Erase all of the package data files. (Not Recoverable)
the files in the AppData directory do not get removed. This results in an error on re-install of the package:The DataMapper was unable to load the following field: 'Languages'
. This is as a result of mismatched configuration versions.Reproduction steps
Install Log
Service Log
Other Logs
The text was updated successfully, but these errors were encountered: