Regarding GetOriginator* usage

As the title suggests i am not sure on where to call GetOriginator* functions and how to 'remember' the returned values
, in the documentation you say:

Quote

Instead do the following:

1) Call GetOriginatorProcessName from OnCreateFile or OnOpenFile event handlers / callbacks;
2) Store obtained information somewhere and store the reference to this information in the UserContext;
3) When you need to check the originator information in some file-related callback, access the stored information via UserContext

I am confused at 1 and 2.

i) As OnCreateFile and OnOpenFile do not have a UserContext arguement how can achieve two?
ii) Can i use GetOriginator* functions in OnPostCreateFile and OnPostOpenFile functions?
iii) If (ii) is not possible then how will i achieve 2?
I assume a file can be opened concurrently from multiple users, so storing on a Dictionary with filenames as keys wont
work.

ii) Can i use GetOriginator* functions in OnPostCreateFile and OnPostOpenFile functions?

Yes, for sure. You may use it in post-operation callback and keep it safely in UserContext associated storage. Additionally, you should keep a reference count in order to find a condition when user context must be freed in OnCloseFile callback.

Just to be certain.
The user context is per file or per User per File?
To clarify, if i have two users(over a file share) accessing the same file, will they both see the same UserContext(so per file) or will each user have a different UserContext(so per User per File)?

Stelios Mavridis wrote:
Will user2 be able to access the UserContext set by user1?

I don't understand who is the user1 and user2. User context is the same withing single filter instance. It doesn't matter who opens the file. Withing filter instance user context not changed. If you create another filter instance, then you will get another unique per-file value of user context.

The user doesn't set context. Your code sets UserContext field and your code is executed in system context in which it was started, not in the context of the caller user. Does this answer your question or I've missed? :)

The user doesn't set context. Your code sets UserContext field and your code is executed in system context in which it was started, not in the context of the caller user. Does this answer your question or I've missed? :)

Not really, but it did make me see that my phrasing could be confusing.
Let me rephrase.

I have a CallbackFilter filtering a directory shared through windows share.
We can find the user that issued the IO in the OpenCallback using GetOriginatorToken, this however is not possible in other callbacks (eg ReadCallback) as you correctly pointed out.

I however have to be able to find the user of a read operation, as different users should get different data/behaviour(eg fail).

I was asking if the UserContext parameter of the ReadCallback is per file, in which case two different users (the user1,user2 in the previous post) would get the same UserContext pointer.

The other scenario is that the UserContext parameter of the ReadCallback is per file and per user.
In that case the two users will get a different UserContext pointer.

I really hope this resolves any confusion caused from the previous post.

Unfortunately it's the system-imposed restriction that all readers of the same file must get the same data. This is because of the system cache. Here's how it works:

The data goes this way:

FS -> FS filter -> system cache -> OS Filesystem API -> Application

The cache is common for all applications. Requests for reading and writing the data do not contain identifier of the calling process because it can be the system itself, filling the cache.

You can control which process opens the file and prevent file opening (if the file can't be opened, it can't be read by the process). But once the file is opened, the process reads the data from the cache or via the cache, but you don't control this on Cache<->Application route.