hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao Chen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-10756) Expose getTrashRoot to HTTPFS and WebHDFS
Date Mon, 31 Oct 2016 22:45:59 GMT

    [ https://issues.apache.org/jira/browse/HDFS-10756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623673#comment-15623673

Xiao Chen commented on HDFS-10756:

Thank you for the new patch, [~yuanbo].

bq. Hoping we can add something like javadoc from DFS to explain this overall.... add a link
to TransparentEncryption.html#Rename_and_Trash_considerations
Sorry for any miscommunication. These comments are for the {{WebHDFS.md}} documentation. No
need to update current javadoc from DFS, but please add similar text to the WebHDFS.md documentation,
and also add a link to {{TransparentEncryption.html#Rename_and_Trash_considerations}} so interested
user can find more details.
Please update the {{HttpFSFileSystem}} javadoc accordingly.

bq. ...it's a wired behavior ... file another JIRA to track such issue
I agree it shouldn't be changed here. Changing that would be incompatible. I think that worths
a discussion first: It appears the fall-back logic was added due to HDFS-9799, to solve an
incompatible behavior in branch-2. But wondering if we should modify 3.0 to a more intuitive
behavior. [~zhz] / [~andrew.wang] / other watchers, thoughts?

> 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, HDFS-10756.002.patch, HDFS-10756.003.patch,
HDFS-10756.004.patch, HDFS-10756.005.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

To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org

View raw message