[
https://issues.apache.org/jira/browse/HDFS-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771222#action_12771222
]
Jakob Homan commented on HDFS-740:
----------------------------------
It looks like Gary did his test slightly differently: in his test the Trash
directory doesn't exist beforehand and there isn't quota available to even
create it. At which point we hit:
{code} for (int i = 0; i < 2; i++) {
try {
if (!fs.mkdirs(baseTrashPath, PERMISSION)) { // create current
LOG.warn("Can't create trash directory: "+baseTrashPath);
return false;
}
} catch (IOException e) {
LOG.warn("Can't create trash directory: "+baseTrashPath);
return false;
}
{code}
This false gets percolated up to FsShell:delete which interprets the failure as
instruction to go ahead with the hard delete:
{code} if (trashTmp.moveToTrash(src)) {
System.out.println("Moved to trash: " + src);
return;
}
}
if (srcFs.delete(src, true)) {{code} It would probably be better to throw and
exception rather than return false, so that the deletion doesn't go ahead.
This is not new behavior, it's been around since at least January (the farthest
back into the repo I went). Looks like it just hasn't been tested.
> rm and rmr fail to correctly move the user's files to the trash prior to
> deleting when they are over quota.
> -------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-740
> URL: https://issues.apache.org/jira/browse/HDFS-740
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 0.20.1
> Reporter: gary murry
>
> With trash turned on, if a user is over his quota and does a rm (or rmr), the
> file is deleted without a copy being placed in the trash.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
