Fixed misspecification of forget behavior for the root inode.

fuseops/ops.go

@@ -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
+// reference count of one, without a corresponding op to increase it. (There
-// is never decremented to zero. Code walk:
+// 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
 

samples/forgetfs/forget_fs.go

@@ -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))
 			}