Provide short term fix for the problem of retrieving mistakenly deleted files from Resources. e.g. Provide way for sysadmins to get at deleted files, even just so they knew where in the backup to look for the file.
Deleted files would not be counted in with the quota, and there would be no UI. (This would be dealt with by )
It looks like it is almost implemented actually - there is a content_resource_delete table that tracks deletions. It has a path field that looks like it is a spot where the deleted resource would be moved to, but the move doesn't actually take place.
Incorporated into SAK-1525, see that Jira for further progress on this issue.
John Leasia July 25, 2007 at 5:27 AM
One way might be to add a column to the content_resource_delete table that is the file's path before the delete.
That is essentially what we have done by the workaround we are trying here in the meantime is to on the Oracle db side. We put in a trigger for content_resource table. Anytime a row is deleted from that table (as happens with a delete), the trigger copies that row first to another table. That gives us the filename (we can get it from the resource_id field) and the file's path (from the file_path field). So, we can check that table and find the path, request the filesystem folks restore the volume and we can retrieve the file from the restored volume.
Reported / Requested by John Leasia, UMich.
Provide short term fix for the problem of retrieving mistakenly deleted files from Resources. e.g. Provide way for sysadmins to get at deleted files, even just so they knew where in the backup to look for the file.
Deleted files would not be counted in with the quota, and there would be no UI. (This would be dealt with by )
It looks like it is almost implemented actually - there is a content_resource_delete table that tracks deletions. It has a path field that looks like it is a spot
where the deleted resource would be moved to, but the move doesn't actually take place.