Provide open and close callbacks to virtual filesystem implementation… #91
Conversation
|
Can one of the admins verify this patch? |
|
ok to test |
…s as described in dCache#38. Signed-off-by: David Kocher <[email protected]>
There was a problem hiding this comment.
I was trying to do something similar, but at the end decided against it. It's not symmetric, e.q. the some calls accept stateid and have a undefined behavior. Have a look at https://github.com/dCache/nfs4j/blob/master/core/src/main/java/org/dcache/nfs/v4/FileTracker.java. I think it's quite close to what you want to achieve.
| @@ -47,6 +47,7 @@ public void process(CompoundContext context, nfs_resop4 result) | |||
| Inode inode = context.currentInode(); | |||
|
|
|||
| stateid4 stateid = Stateids.getCurrentStateidIfNeeded(context, _args.opclose.open_stateid); | |||
| context.getFs().close(inode, stateid); | |||
There was a problem hiding this comment.
This can trigger false evens it client tries to close invalid inode or stateid. I think this should be bound to state disposal
There was a problem hiding this comment.
Makes sense. We have worked around this by tracking the stateid in the virtual filesystem implementation.
| @@ -206,6 +206,7 @@ public void process(CompoundContext context, nfs_resop4 result) throws ChimeraNF | |||
| } | |||
|
|
|||
| context.currentInode(inode); | |||
| context.getFs().open(inode, this.getAccessMode(_args.opopen.share_access), result.opopen.resok4.stateid); | |||
There was a problem hiding this comment.
you will mess all opens by file handle, which is quite common, when client already got hanlde by previous readdir, lookup or open.
|
|
…s as described in #38.
Signed-off-by: David Kocher [email protected]