Flock implementation with test.

[OneOfOne]

Please let me know if it doesn't work as expected.

Fixes #134

[hanwen]

is there no lighter weight mechanism for this? There must be some command-line utility that exposes flock?

[OneOfOne]

There is the flock command but it's part of util-linux-ng, I don't think it's very portable.

[hanwen]

I'd rather use that, and skip the test if we can't find the binary. Running the test binary from within the test binary sounds like it might easily break

[OneOfOne]

@hanwen did you get a chance to look at it?

[hanwen]

squashed and committed as ae2e1d5

[rfjakob]

I think there is still something missing. I have mounted a loopback filesystem with -debug and ran flock in the mountpoint:

$ flock --verbose test.lock sleep 1
flock: getting lock took 0.000005 seconds
flock: executing sleep

loopback debug output:

21:10:32.202610 Dispatch 244: LOOKUP, NodeId: 1. names: [test.lock] 10 bytes
21:10:32.202679 Serialize 244: LOOKUP code: OK value: {NodeId: 4 Generation=2 EntryValid=1.000 AttrValid=1.000 Attr={M0100664 SZ=0 L=1 1026:1026 B0*4096 i0:8782516 A 1493752213.917942455 M 1493752213.917942455 C 1493752213.917661210}}
21:10:32.202791 Dispatch 245: OPEN, NodeId: 4. data: {O_RDONLY,0x8000} 
21:10:32.202834 Serialize 245: OPEN code: OK value: {Fh 3 }
21:10:33.203963 Dispatch 246: FLUSH, NodeId: 4. data: {Fh 3} 
21:10:33.204022 Serialize 246: FLUSH code: OK value: 
21:10:33.204236 Dispatch 247: FLUSH, NodeId: 4. data: {Fh 3} 
21:10:33.204249 Serialize 247: FLUSH code: OK value: 
21:10:33.204308 Dispatch 248: RELEASE, NodeId: 4. data: {Fh 3 0x8000  L0} 
21:10:33.204324 Serialize 248: RELEASE code: OK value: 

As you can see, no FLOCK call! The kernel does not seem to pass the call to us. Maybe we have to set a capability bit when mounting?

[rfjakob]

Ok I think what is missing is that the flock-related operations (_OP_GETLK etc.) are handled in opcode.go

[hanwen]

There was a test (which I didn't run but looked plausible). Are you saying it's completely broken? Op di 2 mei 2017 21:25 schreef rfjakob <[email protected]>:

…

Ok I think what is missing is that the flock-related operations (_OP_GETLK etc.) are handled in opcode.go <https://github.com/hanwen/go-fuse/blob/master/fuse/opcode.go> — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#153 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB7O8VctNhbp1pW5VfUKdJCHFj-pd7uks5r14M5gaJpZM4M-oXx> .

[rfjakob]

Yes it is missing the kernel interface. But, it does no harm, the new code is just never called at the moment.

The test passes because the kernel keeps track of the locks when the filesystem does not support locking.