Is there a way to provide exclusive access to a file?

[tastewar]

In existing Windows app, we would call CreateFile with dwShareMode of 0 (or FILE_SHARE_NONE). Is there any functionality like this in llfio?

[BurningEnlightenment]

No, there is no such functionality as POSIX doesn't provide anything remotely comparable. You can implement this yourself though:

1. Open the file with ::CreateFile
2. Do the usual error handling dance.
3. Wrap the HANDLE with llfio::native_handle_type using the correct disposition flags.
4. Create an actual llfio::file_handle instance with the wrapper and the corresponding flags.

You should consult the current Windows file_handle implementation files to figure out which flags are appropriate.

HTH

[BurningEnlightenment]

Sure, IIRC there's even something like llfio::temp_inode() which can be used today… btw. could a child process inherit access to such a handle?

[ned14]

Yes those inherit to child processes just fine on both Windows and POSIX.

You would need to mark them for inherit (Windows) or mark them to not close on exec (POSIX) manually however. LLFIO defaults to not having child processes inherit handles (for obvious reasons).

[BurningEnlightenment]

Oh and I almost forgot: If you don't need enforced defensive locking and all involved processes are cooperative / under your control, you could use the file range locking facilities provided by llfio to coordinate file access.

[tastewar]

So here's my situation. Rewriting some code that was originally Windows only, and implemented a shared file cache via named memory maps. New implementation will not be shared, so if I were writing it just for Windows, I would use FILE_SHARE_NONE (and I wouldn't be using llfio ;-) ). So I am looking for a way to do this that would work on Linux as well. These are database files, and not temporary files. I have thought about using file range locking. Realistically, all involved processes are cooperative and under my control. It's just a nice failure mode to have the failure happen on the creation of the file handle. There is also the lock_file() function which looks like it might be relevant, but from the doc I can't tell whether it would fail if someone else had already acquired the lock, or if it just waits indefinitely. The void return makes me think maybe the latter, which would be problematic for my use case.

[ned14]

Would exclusive file creation work here for you?

Alternatively, when you open the file you put either a shared or exclusive lock on it. Locks on POSIX don't affect i/o, and how we implement them on Windows doesn't either. They're purely advisory. Shared locks allow multiple lockers, but no exclusive lockers. Exclusive lockers get the file entirely to themselves.

I'd recommend avoiding file range locks unless you are on a new enough Linux only. Any other POSIX they are fundamentally broken and nobody should use them.

Whole file locks work well everywhere however. You may need more than one file to create the appropriate semantics e.g. three files can each have exclusive or shared, and from that you can construct eight-way states, as an example.

I appreciate this is different from what Windows allows, however what works on all platforms identically is necessarily a bit more involved.

Note that there is a try lock file too. We have no timed edition as that isn't portable.