Thanks Chris! Silly me, didn't look at "FsPermissionExtension".
John Zhuge
Software Engineer, Cloudera
On Mon, Sep 19, 2016 at 11:33 AM, Chris Nauroth
wrote:
> Hello John,
>
> That is the ACL bit. The NameNode toggles on the ACL bit in getFileInfo
> responses for inodes that have ACL entries attached to them. On the client
> side, this results in calls to FsPermission#getAclBit returning true.
>
> The purpose of the ACL bit is to help client applications identify files
> and directories that have ACL entries attached. One specific example where
> this is useful is in the output of the file system shell "ls" command.
> (See org.apache.hadoop.fs.shell.Ls#processPath.) If the ACL bit is
> turned on, then this is how the shell decides to append a '+' character
> after the basic permissions, so the end user knows that ACL entries are
> present. If the ACL bit didn’t exist, then applications like this would
> have to be implemented with a more costly FileSystem#getAclStatus call, in
> addition to the existing getFileInfo RPC.
>
> Test cases defined in FSAclBaseTest check for the presence of the ACL bit
> where expected.
>
> --Chris Nauroth
>
> On 9/19/16, 10:55 AM, "John Zhuge" wrote:
>
> Hi Gurus,
>
> Does anyone know the meaning of bit 12 in the permission field of
> "getFileInfo" response? To my understanding, the bit 9 is sticky bit,
> along
> with the lower 9 bits for user/group/other.
>
> In this following trace, the "perm" field is "4584", i.e., "10750" in
> oct:
>
> 16/09/15 15:54:56 TRACE ipc.ProtobufRpcEngine: 1: Response <-
> NAMENODE:8020: getFileInfo {fs { fileType: IS_DIR path: "" length: 0
> permission { perm: 4584 } owner: "USER" group: "supergroup"
> modification_time: 1473884314570 access_time: 0 block_replication: 0
> blocksize: 0 fileId: 8798130 childrenNum: 1 storagePolicy: 0 }}
>
> Thanks,
> John Zhuge
> Software Engineer, Cloudera
>
>
>
