how to track for longer times the file state?

NTFSD
1

Hi,

I’m working on a minifilter and I use file stream contexts to attach
filter specific per-stream attributes & status data to each file stream;
It is very important to access the per-stream status data for a
quite long period of time, even after the file is closed and reopened
after several minutes (some kind of cache). What I have observed is,
that for local file systems (like NTFS) if I set a file stream context
at an arbitrary CREATE request, then that particular file is closed,
the stream context survives for quite a long time if there is no
heavy FSD activity (probably there are FSD / cache specific structures
that keep alive the context?). If, after let’s say 5 minutes I try to reopen
that particular file, in many cases I would still get back the existing
file stream context with all the stored attributes & state data.

On the other hand, if I try to use the same technique for network
based files (accessed through a redirector), I observe that the contexts
are removed very quickly (sometimes in a fraction o a second). So,
if I store some information in a stream context on any create, I will
quickly loose it and will be unable to access it from another create
if the file was closed before (in a new create will get another context
and so on).

  1. Is there any way to keep alive stream contexts for non-local files
    (and, on the other hand for local files also) for an arbitrary long time?

  2. What happens, if I increase the reference counter for local /
    non-local stream contexts and decrease it after 3 minutes for ex?
    AFAIK, the Filter Manager will NOT release the stream contexts
    due to reference counting; but will the underlying FSDs / redirectors
    use the same contexts or will free the FSD specific structs from
    under the context and at a new create will create new FSD specific
    structs with a separate new context?

  3. What happens if I open the non-local files (create a separate handle)
    and keep that handle for 3 minutes? Will this enforce the FSD /
    redirector to keep the correct stream context for a long time? and
    use it for new Create requests? Will such an approach have undesired
    functional impact on other system elements?

Any other idea / solution?

  1. Another question: how could I get notified about changes to non-local
    files in a filter driver? Can I just open a handle to the file (like at
  1. and
    request an OPLOCK LEVEL 2? How could I do this correctly? (some
    example, link would be highly appreciated) This is important, because
    among others I usually need to track changes to files in the stream context;
    for local files this can be easily done using IRP_MJ_WRITE filtering;
    however I don’t know about a good way for network based files. Any
    idea / suggestion?

thank you very much,

Sandor LUKACS
Virus Analyst, BitDefender