[
https://issues.apache.org/jira/browse/HDFS-11091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15685990#comment-15685990
]
Yuanbo Liu commented on HDFS-11091:
-----------------------------------
[~zhz] Sorry to interrupt.
I've read your discussion in HDFS-9799. {{IOException}} in {{getTrashRoot}} and
{{getTrashRoots}} is removed because of compatibility consideration. The idea
in HDFS-9799 is to swallow exception and fall back to default trash root with
warning log, users can aware the trash root is wrong by using {{rm}}
afterwards.
I tag you here because after discussing in HDFS-10756, we still think it's a
surprising behavior to fall back here. I'd propose to throw a run time
exception here. If you have any thought about this JIRA, please let me know,
thanks in advance.
> Implement a getTrashRoot that does not fall-back
> ------------------------------------------------
>
> Key: HDFS-11091
> URL: https://issues.apache.org/jira/browse/HDFS-11091
> Project: Hadoop HDFS
> Issue Type: Improvement
> Affects Versions: 2.8.0
> Reporter: Xiao Chen
> Assignee: Yuanbo Liu
>
> From HDFS-10756's
> [discussion|https://issues.apache.org/jira/browse/HDFS-10756?focusedCommentId=15623755&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15623755]:
> {{getTrashRoot}} is supposed to return the trash dir considering encryption
> zone. But if there's an error encountered (e.g. access control exception), it
> falls back to the default trash dir.
> Although there is a warning message about this, it is still a somewhat
> surprising behavior. The fall back was added by HDFS-9799 for compatibility
> reasons. This jira is to propose we add a getTrashRoot that throws, which
> will actually be more user-friendly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
