[HDFS-10756] Expose getTrashRoot to HTTPFS and WebHDFS

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 2.9.0, 3.0.0-alpha2
• Component/s: encryption, httpfs, webhdfs
• Target Version/s: 2.9.0
• Hadoop Flags: Reviewed

Release Note

"getTrashRoot" returns a trash root for a path. Currently in DFS if the path "/foo" is a normal path, it returns "/user/$USER/.Trash" for "/foo" and if "/foo" is an encrypted zone, it returns "/foo/.Trash/$USER" for the child file/dir of "/foo". This patch is about to override the old "getTrashRoot" of httpfs and webhdfs, so that the behavior of returning trash root in httpfs and webhdfs are consistent with DFS.

• Assignee: Yuanbo Liu
• Reporter: Xiao Chen
• Created: 11/Aug/16 23:59
• Updated: 18/Feb/20 22:26
• Resolved: 05/Nov/16 01:22

Description

Currently, hadoop FileSystem API has getTrashRoot 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 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.

Issue Links

• breaks: HDFS-15181 Webhdfs getTrashRoot() causes internal AccessControlException
• is related to: HDFS-10883 `getTrashRoot`'s behavior is not consistent in DFS after enabling EZ.
• relates to: HDFS-15052 WebHDFS getTrashRoot leads to OOM due to FileSystem object creation