fuse中unlink的策略

看下面一段fuse的输出：

OPEN[0] flags: 0x8000 /home/wcw/tmp/w     //一进程打开了文件w
unique: 21, opcode: LOOKUP (1), nodeid: 4, insize: 42
LOOKUP /home/wcw/tmp/w
    xmp_getattr
   NODEID: 5
   unique: 21, error: 0 (Success), outsize: 136
unique: 22, opcode: UNLINK (10), nodeid: 4, insize: 42  //还没关闭w，就unlink
UNLINK /home/wcw/tmp/w                                  //这时fuse自动把w重命名一临时文件
    xmp_getattr
    xmp_rename, from /home/wcw/tmp/w to /home/wcw/tmp/.fuse_hidden0000000500000001
   unique: 22, error: 0 (Success), outsize: 16
unique: 23, opcode: FLUSH (25), nodeid: 5, insize: 64
FLUSH[0]
   unique: 23, error: -38 (Function not implemented), outsize: 16
unique: 24, opcode: RELEASE (18), nodeid: 5, insize: 64  //当关闭前面的打开的w时
RELEASE[0] flags: 0x8000
    xmp_release
    xmp_unlink /home/wcw/tmp/.fuse_hidden0000000500000001  //fuse再把前面的临时文件删除
   unique: 24, error: 0 (Success), outsize: 16
unique: 25, opcode: FORGET (2), nodeid: 5, insize: 48
FORGET 5/2
delete: 5

这段输出给我提示是：在DNFS中，client端我并不需要再对unlink和其他操作进行互斥等等，fuse已经做好了，当某一进程访问文件w(文件的硬链接>0)，如果进程在应用层unlink该文件，我在文件系统层收到的其实是rename调用，所以我需要做的是rename与open和release之间的关系，而不是unlink和其他操作的关系。