Fixed misspecification of forget behavior for the root inode.

geesefs-0-30-9
Aaron Jacobs 2015-03-31 15:25:20 +11:00
parent a336c82f2a
commit 2dd919f8f3
2 changed files with 11 additions and 4 deletions

View File

@ -241,8 +241,9 @@ func (o *SetInodeAttributesOp) Respond(err error) {
// revalidating.
//
// In contrast to all other inodes, RootInodeID begins with an implicit
// reference count of one, without a corresponding op to increase it. It also
// is never decremented to zero. Code walk:
// reference count of one, without a corresponding op to increase it. (There
// could be no such op, because the root cannot be referred to by name.) Code
// walk:
//
// * (http://goo.gl/gWAheU) fuse_fill_super calls fuse_get_root_inode.
//
@ -251,6 +252,9 @@ func (o *SetInodeAttributesOp) Respond(err error) {
//
// * (http://goo.gl/vPD9Oh) fuse_iget increments nlookup.
//
// File systems should not make assumptions about whether they will or will not
// receive a ForgetInodeOp for the root inode. Experimentally, OS X seems to
// never send one, while Linux appears to send one only sometimes.
type ForgetInodeOp struct {
commonOp

View File

@ -184,9 +184,12 @@ func (fs *fsImpl) Check() {
defer fs.mu.Unlock()
for k, v := range fs.inodes {
// Special case: the root inode should have an implicit lookup count of 1.
// Special case: we don't require the root inode to have reached zero.
// OS X doesn't seem to send forgets for the root, and Linux only does
// sometimes. But we want to make sure it's not greater than one, which
// would be weird.
if k == fuseops.RootInodeID {
if v.lookupCount != 1 {
if v.lookupCount > 1 {
panic(fmt.Sprintf("Root has lookup count %v", v.lookupCount))
}