ShareMode in WinFSP

[Juraj Ahel]

Dear Bill / everyone,

I'm trying to make a passthrough-like fs that has some additional features, for which it seems to me I'd need the info about what share mode the client requested for the file.

We have some instrument software that passes data generated by the instrument into a file. Generating a single "measurement file" takes about an hour, and during this period the software has an exclusive rw lock on the file, preventing us from stream-processing the data.

I wanted to use WinFSP to create a proxy FS for the instrument software to write to, that would override the locks and let us read the file as it's being written to. The default passthrough implementation does fulfil this, but in an unsafe way. The proxy FS will respect the share constraints, but the underlying passthrough FS will apply no constraints at all, i.e. I can read/write/delete regardless of the ShareMode requested on proxy FS's file, which opens a way to data corruption by any process having access to the underlying passthrough FS. 

It's clear why this is so - the default passthrough implementation simply uses hardcoded 
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE as ShareMode. But I can't figure out how I could do it in a different way, or if it's even possible with WinFSP.

I can hardcode the access to  FILE_SHARE_READ instead. This would make it safe but very restricted and not fully suitable for our purposes - it's not possible to rename any file in proxy FS, even when not opened by a different process.

I saw in a comment somewhere written that  ShareMode is handled transparently by WinFSP's FSD, which I can see in the behavior of the FS on the user mode FS side - but is it at all possible to access the requested ShareMode in the API, whether C or .NET?

This seems to me relevant not only for our case but any case where conditional locking might be desired, e.g. a database-backed FS, or any situation where the underlying storage has multiple access interfaces (winFSP user mode FS + a different access interface).

I saw that Dokan exposes ShareAccess in its calls, so in principle it's probably a viable alternative for us, but my understanding is WinFSP has superior performance, which is possibly relevant in our case, as the instrument generates a significant amount of data.

Many thanks for any info!

Best,

Juraj

[Bill Zissimopoulos]

Hello:

 

The WinFsp API does not directly expose the ShareAccess because it is handled transparently for most file systems in the FSD. However it is available when using the C API, using the following incantation:

 

FspFileSystemGetOperationContext()->Request->Req.Create.ShareAccess

 

This is only valid during Create/Open calls.

 

Thank you.

 

Bill

--
You received this message because you are subscribed to the Google Groups "WinFsp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to winfsp+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/winfsp/7602e3f0-bd72-4d70-96fb-81a5ba80460en%40googlegroups.com.