[
https://issues.apache.org/jira/browse/HADOOP-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen O'Malley resolved HADOOP-18144.
------------------------------------
Fix Version/s: 3.4.0
Resolution: Fixed
> getTrashRoot/s in ViewFileSystem should return viewFS path, not targetFS path
> -----------------------------------------------------------------------------
>
> Key: HADOOP-18144
> URL: https://issues.apache.org/jira/browse/HADOOP-18144
> Project: Hadoop Common
> Issue Type: Improvement
> Components: common
> Reporter: Xing Lin
> Priority: Major
> Labels: pull-request-available
> Fix For: 3.4.0
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> It is probably incorrect that we return a targetFS path from getTrashRoot()
> in ViewFileSystem, as that path will be used later on by ViewFileSystem in
> other operations, such as rename. ViewFileSystem is assuming the path that it
> receives is a viewFS path, but not a target FS path. For example, rename() in
> ViewFileSystem will call getUriPath() for src/dst path, which will remove the
> scheme/authority and then try to resolve the path-only component. It thus
> sometimes leads to incorrect path resolution, as we are doing the path
> resolution again on a targetFS path.
>
> On the other hand, it is not always trivial/feasible to determine the correct
> viewFS path for a given trash root in targetFS path.
> Example:
> Assume we have a mount point for /user/foo -> abfs:/containerA
> User foo calls getTrashRoot("/a/b/c") and "/a/b/c" does not match any mount
> point. We fall back to the fallback hdfs, which by default returns
> hdfs://localhost/user/foo/.Trash. In this case, it is incorrect to return the
> trash root as viewfs:/user/foo, as it will be resolved to the abfs mount
> point, instead of the fallback hdfs.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
