[ 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)