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" <jzh...@cloudera.com> 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
    

Reply via email to