Test use of flock(2)

[kivikakk]

We need to ensure that our flock(2)-based synchronisation actually works. We flock(2) in two scenarios:

• when hydrating a directory with placeholders; and,
• when hydrating a placeholder file.

If our synchronisation failed, we would expect that attempting to enumerate an unhydrated directory or access an unhydrated placeholder would block while the provider does the work, but that a second concurrent attempt would not block and wait for the first, and instead would overlap with it. This could cause data corruption, or a crash.

To test, we create a provider which, on projection request, opens a file with O_CREAT|O_EXCL, sleeps 1 second, then removes the file. We then try to list the directory contents twice, concurrently. If the file open fails with EEXIST (in one of the attempts), this implies the provider was called to project the same directory twice concurrently, and that libprojfs didn't synchronise access correctly.

[chrisd8088]

We should be able to add a TEST_OPT_LOCKFILE option, say, which maybe takes the filename/path of the file to be created, plus the TEST_OPT_TIMEOUT option. Then you'd run:

test_projfs_handlers ... --timeout 1 --lock-file path/to/test.lock ...

and in the event handler, read those values using test_get_opts(). If --lock-file is specified, create the file, and we could have a default timeout if --timeout wasn't specified.

I'd suggest maybe using this new value (in test_common.h) because that should reduce collisions with the stuff coming from the projection-test-lists* branches:

#define TEST_OPT_NUM_LOCKFILE 6

Thanks for looking at this, @kivikakk!

[kivikakk]

Thank you very much for this detailed feedback! I wasn't sure if this would be too much.

I'll need to use 4 as they need to correspond to valid indices into the options arrays; we can renumber on merge.

[kivikakk]

➡️ #51