[
https://issues.apache.org/jira/browse/HDFS-10756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15432121#comment-15432121
]
Xiao Chen commented on HDFS-10756:
----------------------------------
Thank you for working on this, [~yuanbo]. Idea looks good.
I don't have a strong feeling regarding splitting the jira. If we're splitting
though, I'd prefer we have just 2 jiras for webhdfs and httpfs respectively,
and both include their own doc changes.
Some comments:
* In both implementations' {{getTrashRoot}}:
** I see we return null when an IOE is caught. This is not the same behavior as
dfs, which always returns {{super.getTrashRoot(path);}}.
** {{LOG.warn("can not find trash root of " + p);}}: Since we're using slf4j,
let's use place holders when logging. Also, suggest s/can not/Cannot/g here.
* FSOperations.java
** Suggest we keep the whitespace as-is, to minimize our change.
** {{@InterfaceAudience.Private}} should be on a separate line on its own.
* NamenodeWebHdfsMethods.java
** {{getTrashRoot}}'s inner comment is not accurate. {{queryPath.isRoot() ==
true}} doesn't mean it is not an EZ. If {{/}} is an EZ, we choose to user's
home dir because it's under {{/}} as well. How about we add a javadoc to the
method, and remove the comment here?
* Test
** Can we add a case to verify nested ez's trash dir works too?
* Please fix the checkstyles when jenkins comes back.
> Expose getTrashRoot to HTTPFS and WebHDFS
> -----------------------------------------
>
> Key: HDFS-10756
> URL: https://issues.apache.org/jira/browse/HDFS-10756
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: encryption, httpfs, webhdfs
> Reporter: Xiao Chen
> Assignee: Yuanbo Liu
> Attachments: HDFS-10756.001.patch
>
>
> Currently, hadoop FileSystem API has
> [getTrashRoot|https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileSystem.java#L2708]
> to determine trash directory at run time. Default trash dir is under
> {{/user/$USER}}
> For an encrypted file, since moving files between/in/out of EZs are not
> allowed, when an EZ file is deleted via CLI, it calls in to [DFS
> implementation|https://github.com/apache/hadoop/blob/trunk/hadoop-hdfs-project/hadoop-hdfs-client/src/main/java/org/apache/hadoop/hdfs/DistributedFileSystem.java#L2485]
> to move the file to a trash directory under the same EZ.
> This works perfectly fine for CLI users or java users who call FileSystem
> API. But for users via httpfs/webhdfs, currently there is no way to figure
> out what the trash root would be. This jira is proposing we add such
> interface to httpfs and webhdfs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
