[
https://issues.apache.org/jira/browse/HADOOP-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517985
]
dhruba borthakur commented on HADOOP-1665:
------------------------------------------
I agree that the location of the file in /Trash might not be enough to
determine the latest copy of the file. One can use the "last modification time"
of the file to determine the latest copy of the file in Trash (this approach is
not foolproof either). However, I think the most common cases are addressed by
this patch.
I would hesitate to decrease the replication factor when it gets moved to Trash.
> DFS Trash feature bugs
> ----------------------
>
> Key: HADOOP-1665
> URL: https://issues.apache.org/jira/browse/HADOOP-1665
> Project: Hadoop
> Issue Type: Bug
> Components: dfs
> Affects Versions: 0.13.1
> Reporter: Nigel Daley
> Assignee: dhruba borthakur
> Priority: Blocker
> Fix For: 0.14.0
>
> Attachments: Trash2.patch
>
>
> In testing the DFS Trash feature, I've run across a couple of bugs.
> 1) Attempting to remove the same file fails when attempted within the same
> fs.trash.interval:
> % bin/hadoop dfs -put file /file
> % bin/hadoop dfs -rm /file
> Moved to trash: /file
> % bin/hadoop dfs -put file /file
> % bin/hadoop dfs -rm /file
> rm: Failed to move to trash: /file
> 2) Removing a file within a directory, followed by removing the directory
> creates a bizzare hierarchy within /Trash:
> % bin/hadoop dfs -mkdir /dir
> % bin/hadoop dfs -put file /dir/file
> % bin/hadoop dfs -rm /dir/file
> Moved to trash: /dir/file
> % bin/hadoop dfs -rmr /dir
> Moved to trash: /dir
> % bin/hadoop dfs -lsr /Trash
> /Trash/Current <dir>
> /Trash/Current/dir <dir>
> /Trash/Current/dir/dir <dir> <-- This is weird; potentially related
> to a rename case not fixed by HADOOP-1623 ???
> /Trash/Current/dir/file <r 3> 10
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
