[
https://issues.apache.org/jira/browse/HADOOP-18801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17742274#comment-17742274
]
Xiaoqiao He commented on HADOOP-18801:
--------------------------------------
Hi [~ayushtkn],
In my practice, this case does exists. Someone rename to trash using filesystem
interface directly, such as `fs.rename(new Path("/foo/bra"), new
Path("/user/someone/.Trash/"));` but it does not check if dest is Trash home or
not at namenode side. So I offer solutions
(https://github.com/apache/hadoop/pull/5744#issuecomment-1592781982),
a. forbid to move one path to home of Trash. Or
b. Emptier clean some directory at home of Trash which is not under checkpoint
directory.
For this case, it is not relate to `skipTrash`. Thanks
> Delete path directly when it can not be parsed in trash
> -------------------------------------------------------
>
> Key: HADOOP-18801
> URL: https://issues.apache.org/jira/browse/HADOOP-18801
> Project: Hadoop Common
> Issue Type: Improvement
> Reporter: farmmamba
> Assignee: farmmamba
> Priority: Major
> Labels: pull-request-available
>
> If we move path to trash dir directly rather than use delete API or rm
> command, when
> invoke deleteCheckpoint method, it will catch ParseException and ignore
> deleting the path. It will never be deleted, so we should do something to
> prevent or monitor it.
> Some logs are listed below.
>
> {code:java}
> WARN org.apache.hadoop.fs.TrashPolicyDefault: Unexpected item in trash:
> /user/de_eight/.Trash/college_geek_job_recall_als_modelres_5_2_6.del.
> Ignoring.
> WARN org.apache.hadoop.fs.TrashPolicyDefault: Unexpected item in trash:
> /user/de_eight/.Trash/college_geek_addf_vector. Ignoring.
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
