只有64位，如何存下hadoop的权限信息？

今天我们来聊聊hadoop中文件的权限信息是怎么保存的，我先来揭晓答案吧，原来如此强大的权限系统只用了一个java的长整型就保存了这些信息。惊不惊喜，意不意外！

这个长度仅有64位的空间是如何存下的呢？我们接着说，通过查看代码，我们发现文件的权限信息保存在PermissionStatusFormat结构中，这个结构主要存储了3个字段信息，分别为：

1.MODE

2.GROUP

3.USER

和linux文件系统一样，通过这三个字段可以记录文件所属的用户，组和linux最神奇的777读写执行权限。而hadoop正是学习了这个设计原理。

我们看一个linux文件权限的例子：

 

如图所示，test.c这个文件是属于using组，同时属于using用户，文件的组和所属用户及其它用户的权限为:-rw-rw-r--。

好了，了解了这个概念后，我们就来看看hadoop的文件权限是如何在64位里保存这三个信息的。

为了方便理解，我整理了一个图可以直观的表现这三个信息的存储关系。

 

如图所示，MODE信息是保存在最开始的16位中，可以用一个short类型保存；GROUP信息保存在接下来的25位中，USER信息保留在最后的23位中。

首先，我们看一下MODE信息，该信息保存在FsPermission类型中，实际使用了short类型的12位。分别代表stickyBit，用户权限(useraction)，组权限(groupaction)，其它权限(otheraction)。

0000 000 000 000 000

stickyBit我们暂时不用管，有兴趣的朋友可以看一下最后面我在网上找的一段解释。

除stickyBit信息以外，其它三个信息保存在FsAction枚举类型中。对应的值如下所示：

 

下面我们举例来说明一下，我们新建一个FsPermission对象初始值为0。如下所示：

000 000 000

假设有一个文件的权限为755。这是我们最常用的权限，表示文件所属用户有读写权限，其它只有读权限，根据上表可以表示为：

useraction=111

groupaction=101

otheraction=101

FsPermission最终值为：

111 101 101

喜欢源码的朋友可以看如下源码。

 

好了，先写到这吧，关于GROUP和USER的存储方式我们下文再说。免得一篇太长。大家看着累。GROUP和USER的存储方式更加有意思，尽请期待。

附：

stickyBit：

粘滞位权限便是针对此种情况设置，当⽬录被设置了粘滞位权限以后，即便⽤户对该⽬录有写⼊权限，也不能删除该⽬录中其他⽤户的⽂件数据，⽽是只有该⽂件的所有者和root⽤户才有权将其删除。设置了粘滞位之后，正好可以保持⼀种动态的平衡：允许各⽤户在⽬录中任意写⼊、删除数据，但是禁⽌随意删除其他⽤户的数据。