Struct FileSystemNode

BaseServer/fileSystem.go:94–119

}

type FileSystemNode struct {
	// 在此文件下创建新文件时要传入的参数
	fileType   int       // 三种文件类型; 不支持链接文件
	readACLs   *[]uint64 // 读权限access control lists
	writeACLs  *[]uint64 // 写权限,请求任意类型的锁都需要写权限
	modifyACLs *[]uint64 // 修改此节点ACL的权限列表
	fileName   string    // 此文件的名称

	instanceSeq uint64 // 实例编号:大于任意先前的同名节点的实例编号
	tokenSeq    uint64 // 锁生成编号:当节点的锁从空闲状态转换到被持有状态时，这个值会增加。用于在持有锁超时时取消上一个seq的权限
	aCLsSeq     uint64 // ACL生成编号：当写入节点的 ACL 名称时，这种情况会增加。	// 目前没有看懂有什么用处

	// 本来想加入FileSystemNode地址,但是go的栈会变,所以打消了这个念头
	// 因为在文件描述符期间instanceSeq不会改变,但总体是改变的;
	// 如此看来Checksum不一定是整个结构体的某种校验和,只要保证随机性就ok了;这句话想的大错特错,因为每个节点会受到相同的checksum,如果多个节点生成的不一样会导致leader成功,其他节点失败
	checksum uint64 // 返回客户端用以构造一个难以被伪造的文件描述符

	OpenReferenceCount     uint64 // open的引用计数,主要用于文件夹,可以理解为文件的描述符没什么意义,文件有意义的是LockType
	nowLockType            int    // 目前的上锁类型,有三种情况
	readLockReferenceCount uint64 // 读锁的引用计数

	// 提供的锁是建议性锁，也就是不加锁也可以通过get，put操作对于文件内容进行操作，不过只提供string的存储，客户可以自定义协议
	nowPath       string                     // 标记当前的路径，用于从raft日志字典中获取此文件中存储的值
	nextNameCache map[string]uint64          // 其实就是下一级的InstanceSeq;当该节点是文件时此字段无效
	next          map[string]*FileSystemNode // 使用map可以更快的找到下一级的全部文件节点，且有序;当该节点是文件时此字段无效
}

/*
 * @brief: 基于FileSystemNode生成一个新的CheckSum; 其实保证随机性就ok了;我这种生成方式最大程度与文件有关