[ http://issues.apache.org/jira/browse/HADOOP-432?page=comments#action_12458360 ] Doug Cutting commented on HADOOP-432: -------------------------------------
> the namenode would thus need to export an API similar to 'find /trash -mmin > +n' First, listing all the files in the trash every half hour or so shouldn't be too big of a burden. Even if it is, then we could create a sub-directory for each ten-minute interval, named by its time of creation. Then one could quickly find all files that need to be deleted without listing the full trash. > You'd also need an efficient way to get the size of the trash externally. We already support server-side du for directories in DFS. Calling it every half hour or even every ten minutes on the trash should not be too great of a burden. So I'd still prefer to see this as a FileSystem-independent implementation. > 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 > Attachments: undelete12.patch, undelete16.patch, undelete17.patch > > > 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
