Isolation driver FO fields copy doubt.

NTFSD
1

Hi,

In the isolation driver I’m building, I have a doubt on how to handle some FO fields, if I have to copy them to the shadow FO and/or copy them back to the upper FO on call return.

In some nt/zw apis, the code first tries to use a Fast I/O path otherwise builds and sends an IRP but FO fields may vary how the request is done. For e.g., if the Synchronous flag is enabled.

Some FO fields I have doubt:

CurrentByteOffset, DeletePending, Flags, LockOperation, LastLock, AdvancedFcbHeader.Flags to say some.

For e.g., I must verify the LockOperation field and threads adding locks and send unlockall requests manually on cleanup.

Regards,
Mauro.

2

I believe you are on a wrong path if you need to copy these fields.

They are managed either by the system or FSD that initialized file object.

If FSD/Filter logic requires to change CurrentByteOffset for a file object initialized by this FSD/Filter it changes it independent of the “shadow FO”.

You should never change any field for a file object initialized by another FSD/Filter or copy any field from this file object.

This is also a bad idea to manage your filter control flow by underlying FSD file object fields as they can be changed asynchronously as a result of the Memory Manager or Cache Manager activity.

3

> I believe you are on a wrong path if you need to copy these fields.

“Up to a point”.

Answering the question for the FileObject and Advanced FCB Header in the
whole (rather than specific fields):

The File Object (and indeed the Advanced FCB Header) is a shared object some
of the fields are owned by Cc, some are owned by the FSD and some need to be
owned by a Shadow FO Filter (no use of cache) and some by Isolation Filters
(use of cache).

In some cases it is *bits* which need to be managed separately. For
instance FO_CLEANUP is set by FAT, but not by NTFS, so an Shadow FO filter
can do what it wants. OTOH it has to own CurrentByteOffset.

To make this more exciting what each field is used for and who owns it is
not documented anywhere that I have found. So its a long experiement to
find what you particular environment needs.

But NEVER copy fields blindly. (Try to) Understand what they are used for
any why you need to copy them or you may end up in a deeper pit.

R

4

Thanks for the answer.

Not sure why, but I have to copy LockOperation from the shadow FO and, on cleanup, send an unlock-all down, else a process cannot lock the same byte range of the same file previously locked in another process.

Based on what you say, can I assume the kernel will never touch or read the upper FO directly?

Regards,
Mauro.

5

If I don’t copy CurrentByteOffset back and forth, IFS tests fails :frowning: