wouldn't it be interesting to have a flag in file-storage wether it should really delete files or simply flag them as deleted or archived just like communities?
When an item is deleted folder-chunk will not display the file anymore. now who should still see the files? I assume administrator of the current folder right? thus I would recommend a second list in folder-chunk that displays deleted items to admins.
The question is now: what if a user tries to create an item that has the same name of an existing deleted one?
There will be a bulk action to set the status of an item and subitems to live again.
From what I see file storage for or less forwards removal to content repository. therefore I will place a parameter check in delete.tcl that will call two new procs for archiving items instead of calling fs::delete_folder or fs::delete_file.
does this approach sound acceptable?
If one needs a soft delete, why not thinking about moving these files into a trash directory? This is a metaphor familiar to most users. It is as well much easier to address naming issues (the name clash when recreating a soft-deleted file in the same directory does not happen; the name clash after the second delete of the same file in the trash folder can be handled by e.g. appending suffixes, similar to Mac OS X).
There could be a central trash folder for each user or a local in each folder. Usually a user would expect that the recovered file is moved back to where it was, right? I guess CR does not track movements of files. So either I have to store that data a local trash folder?
Something else that might be important are permissions. When a file or folder is moved are explizit permissions moved as well? At least this I see in the log "Deleting associated permissions...". I was not able to confirm since moving a file is broken at least in my current HEAD installation. I always get
[13/Jun/2007:09:25:46][3030.3060222864][-conn:15-] Error: Aborting transaction due to error:
Query did not return any rows.
and a message:
There was a problem moving the following items...
An alternative would be "archive". Gmail started by not offering the option to delete messages, but actually went back and added a delete option b/c people wanted to actually "nuke" messages. They have both options now: delete and archive.
Make sure you ask Daveb about how he implemented the CR image upload plugin for us. It gives a unique URL to images and files in the CR. Might be a useful concept as you think about how to do this.
Also if the change is reflected in the CR we'll need to TIP it and get OCT approval.
I like the carl/gustaf notions better than adding a "hidden" flag to cr_items. an "archive" option with one archive per file storage instance seems better to me than your original idea.