[ http://issues.apache.org/jira/browse/HADOOP-432?page=comments#action_12458345 ] Yoram Arnon commented on HADOOP-432: ------------------------------------
that idea came up in the original discussions. since removing files from the trash is done based on age, an external process would need access to that information. the namenode would thus need to export an API similar to 'find /trash -mmin +n', and expose that externally (get only files deleted more than n minutes ago, to avoid repeatedly getting long lists of files that don't need to get deleted yet). You'd also need an efficient way to get the size of the trash externally. So there's no avoiding doing some work in the namenode. Implementing everything internally in the namenode seemed like the simpler way to go, minimizing code, API changes and complexity. > 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
