mirror of
https://github.com/clearlinux/swupd-client.git
synced 2026-09-06 05:32:01 +00:00
William Douglas
02d276564d
Currently sys_rm_recursive was used in any instance of deleting swupd content from the system (update, repair and bundle-remove). This can cause user data loss when unkown files are in directories that swupd is deleting. To prevent this, this patch changes how deleting content in swupd operates. Swupd content removal is now done with sys_rm and the return value is checked in case the removal failed due to a directory that still had files in it. When this specific failure occurs, the directory is added to a new list for reprocessing removals as it is expected once the rest of the deletes on the system occur the failures will go away as the directories will be empty (these deletes are processed in alphabetical reverse order so leaf directories are processed first). If the removal fails again it is presumed the contents of the directory are not files swupd knows about and as such should be kept somewhere else. For handling the retention of user data, directories (with only the content unknown to swupd) are renamed (currently using a .deleted.$timestamp. prefix of the old name) and stored at the same directory level they were previously found with one exception. The exception is for nested deleted content best illustrated with an example: /swupd-dir1/user-file1 /swupd-dir1/swupd-dir2/user-file2 When swupd tries to remove the /swupd-dir1 content, it will store the user files as follows: /.deleted.$timestamp1.swupd-dir1/user-file1 /.deleted.$timestamp1.swupd-dir1/.deleted.$timestamp1.swupd-dir2/user-file2 To demarcate what was part of swupd content vs user content. Signed-off-by: William Douglas <william.douglas@intel.com>