hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-5650) Remove AclReadFlag and AclWriteFlag in FileSystem API
Date Wed, 11 Dec 2013 01:20:15 GMT

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

Chris Nauroth commented on HDFS-5650:

bq. The v2 patch flatten the Acl class into the AclStatus class, which makes it more amenable
for serialization.

This means that we no longer have a class suitable for use in the NameNode implementation,
where we wanted to reuse {{Acl}} instances between multiple files.  ({{AclStatus}} includes
the owner/group of one specific file, so it isn't suitable.)

Are you suggesting that we make {{Acl}} internal to HDFS?  We could do that.  The implementation
would be somewhat duplicated (basically {{AclStatus}} minus 

> 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
>            Reporter: Haohui Mai
>            Assignee: Haohui Mai
>         Attachments: HDFS-5650.000.patch, HDFS-5650.001.patch, HDFS-5650.002.patch, HDFS-5650.003.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

View raw message