[
https://issues.apache.org/jira/browse/HDFS-5650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13845718#comment-13845718
]
Chris Nauroth commented on HDFS-5650:
-------------------------------------
I have one more note on part of the change here. We remove the path member
from {{AclStatus}}. The only reason for the path member was to support
recursive getfacl. If the recursion had been done server-side, then the result
set would have needed to specify the file for each returned ACL. Now that
recursion will be driven from the client side, we don't need this member
anymore. FsShell will always know which path it was working on, so it can
still print each file during a recursive getfacl.
> Remove AclReadFlag and AclWriteFlag in FileSystem API
> -----------------------------------------------------
>
> Key: HDFS-5650
> URL: https://issues.apache.org/jira/browse/HDFS-5650
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client, namenode, security
> Affects Versions: HDFS ACLs (HDFS-4685)
> Reporter: Haohui Mai
> Assignee: Haohui Mai
> Fix For: HDFS ACLs (HDFS-4685)
>
> Attachments: HDFS-5650.000.patch, HDFS-5650.001.patch,
> HDFS-5650.002.patch, HDFS-5650.003.patch, HDFS-5650.004.patch,
> HDFS-5650.005.patch
>
>
> AclReadFlag and AclWriteFlag intended to capture various options used in
> getfacl and setfacl. These options determine whether the tool should traverse
> the filesystem recursively, follow the symlink, etc., but they are not part
> of the core ACLs abstractions.
> The client program has more information and more flexibility to implement
> these options. This jira proposes to remove these flags to simplify the APIs.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
