I discovered a bug where, if a file is queued up for restore, and then another backup of that file is completed before the file is restored, the file will effectively disappear from the restore queue. This is because the logic in add_or_update_file_for_device always deletes records matching the device ID and full path before inserting a new file object into the database. Thus, a new file object ID is created which doesn't match the fileobjectid sitting in the restore queue.
This is probably a pretty rare case to occur in reality and really only happened because of the way I have been splitting up my testing, but we should fix it regardless.
I think probably the cleanest fix is to change the logic in the add_or_update_file_for_device stored procedure to update any existing file object records instead of deleting and re-inserting, to preserve the original FileObjectID.
runt1me
commented
8 months ago
I discovered a bug where, if a file is queued up for restore, and then another backup of that file is completed before the file is restored, the file will effectively disappear from the restore queue. This is because the logic in add_or_update_file_for_device always deletes records matching the device ID and full path before inserting a new file object into the database. Thus, a new file object ID is created which doesn't match the fileobjectid sitting in the restore queue.
This is probably a pretty rare case to occur in reality and really only happened because of the way I have been splitting up my testing, but we should fix it regardless.
I think probably the cleanest fix is to change the logic in the add_or_update_file_for_device stored procedure to update any existing file object records instead of deleting and re-inserting, to preserve the original FileObjectID.