[ http://issues.apache.org/jira/browse/HADOOP-432?page=comments#action_12437016 ] Konstantin Shvachko commented on HADOOP-432: --------------------------------------------
I think the name node changes related to the introduction of recycle bin should be minimal. delete() should work the same as it does now. As an example, lets say I remove file from a C program. Does it go to the recycle bin? No. And we want the same for our map reduce programs. Users are different they need to be protected from themselves but that could be done on the client side. Meaning that DFSShell should call throwToTrash() method when users say delete, instead of calling the real delete(). throwToTrash() should call rename(), and move file from its original location to the trash folder. So far no new name node functionality is required. The only thing that is required from the name node is the trash folder maintenance. I agree with Paul in that rather than starting a new daemon we can check the trash folder for expired or over the limit files each time a new file is created or remove. > support undelete, snapshots, or other mechanism to recover lost files > --------------------------------------------------------------------- > > Key: HADOOP-432 > URL: http://issues.apache.org/jira/browse/HADOOP-432 > Project: Hadoop > Issue Type: Improvement > Components: dfs > Reporter: Yoram Arnon > Assigned To: Wendy Chien > > currently, once you delete a file it's gone forever. > most file systems allow some form of recovery of deleted files. > a simple solution would be an 'undelete' command. > a more comprehensive solution would include snapshots, manual and automatic, > with scheduling options. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira