Yang Jie created HADOOP-20069:
---------------------------------
Summary: TrashPolicyDefault#moveToTrash compares paths as strings,
so ~/.Trash_old is deleted without the trash and a prefix of the home directory
cannot be moved to it
Key: HADOOP-20069
URL: https://issues.apache.org/jira/browse/HADOOP-20069
Project: Hadoop Common
Issue Type: Bug
Components: fs
Reporter: Yang Jie
moveToTrash() decides whether a path is already in the trash, and whether it
contains the trash, with string prefix checks:
{code:java}
if (qpath.startsWith(trashRoot.toString())) {
return false; // already in trash
}
if (trashRoot.getParent().toString().startsWith(qpath)) {
throw new IOException("Cannot move \"" + path +
"\" to the trash, as it contains the trash");
}
{code}
Neither respects path component boundaries:
* {{hadoop fs -rm -r /user/alice/.Trash_old}} run by alice: the path starts
with /user/alice/.Trash, so moveToTrash() returns false and Delete falls back
to fs.delete(). The directory is deleted permanently and the shell prints
"Deleted ..." instead of "Moved: ... to trash at: ...".
* {{hadoop fs -rm -r /user/etl}} run by etl_prod: /user/etl_prod starts with
/user/etl, so the command fails with "Cannot move "/user/etl" to the trash, as
it contains the trash. Consider using -skipTrash option".
Encryption zone and snapshot trash roots have the same problem, e.g.
/ez/.Trash/alice and /ez/.Trash/alice2.
The fix compares whole path components. Paths that are inside the trash, or
that contain it, are handled as before.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
