FsContext - does it come back null?

I have a question concerning the FsContext field of the file object. I
understand that only one FsContext exists for each open file, no matter
how many applications open it. I also know that the file system doesn’t
close or release or whatever, the FsContext pointer until the last
reference to the file is closed. The question I have is this: If I am
tracking a particular FsContext, will that pointer be NULL in the
completion routine for IRP_MJ_CLOSE in my filter driver for the last
reference to the file? I seem to be faced with an FsContext pointing to
one file initially and then later pointing to another file. This is
causing me to decrypt data that wasn’t encrypted! Bad News! Can an
FsContext point to one file and then another without my filter driver’s
knowledge or am I chasing a bug in my FsContext tracking code?

Thanks,
Scott

What are you filtering? What version of the OS? There are some cases *I*
know about here but they are specific to version/file systems.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Scott Elliott [mailto:scottel@us.ibm.com]
Sent: Thursday, April 11, 2002 1:22 PM
To: File Systems Developers
Subject: [ntfsd] FsContext - does it come back null?

I have a question concerning the FsContext field of the file object. I
understand that only one FsContext exists for each open file, no matter
how many applications open it. I also know that the file system doesn’t
close or release or whatever, the FsContext pointer until the last
reference to the file is closed. The question I have is this: If I am
tracking a particular FsContext, will that pointer be NULL in the
completion routine for IRP_MJ_CLOSE in my filter driver for the last
reference to the file? I seem to be faced with an FsContext pointing to
one file initially and then later pointing to another file. This is
causing me to decrypt data that wasn’t encrypted! Bad News! Can an
FsContext point to one file and then another without my filter driver’s
knowledge or am I chasing a bug in my FsContext tracking code?

Thanks,
Scott


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

I am filtering all files in a certain directory on a hard drive.
Currently I’m working on Win2k FAT. However, I hoping for support on
WinNT4.0/Win2k/WinXP for both NTFS and FAT (no other file systems will be
suported).

While I’m at it, I have another question. Is the file size set before
data is written to the file. For example: Start with Test.txt, size 25
bytes. Write 4300 more bytes to Test.txt. When is the size of Test.txt
set to 4325? Before the write or after the write?

Thanks!!
Scott

What are you filtering? What version of the OS? There are some cases *I*
know about here but they are specific to version/file systems.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Scott Elliott [mailto:scottel@us.ibm.com]
Sent: Thursday, April 11, 2002 1:22 PM
To: File Systems Developers
Subject: [ntfsd] FsContext - does it come back null?

I have a question concerning the FsContext field of the file object. I
understand that only one FsContext exists for each open file, no matter
how many applications open it. I also know that the file system doesn’t
close or release or whatever, the FsContext pointer until the last
reference to the file is closed. The question I have is this: If I am
tracking a particular FsContext, will that pointer be NULL in the
completion routine for IRP_MJ_CLOSE in my filter driver for the last
reference to the file? I seem to be faced with an FsContext pointing to
one file initially and then later pointing to another file. This is
causing me to decrypt data that wasn’t encrypted! Bad News! Can an
FsContext point to one file and then another without my filter driver’s
knowledge or am I chasing a bug in my FsContext tracking code?

Thanks,
Scott


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

Scott,

I know of no problems using FAT or NTFS on Windows 2K when tracking the
FsContext value (that is, it doesn’t “change” in the fashion you described).
Pete’s point about the reference counting is valid, although this is much
more an issue when filtering NTFS than when filtering FAT. Thus, this
sounds like it is most likely a bug in your own tracking/reference counting
code.

The file size is set by the user-level write operation. Some user
applications also call and set the EOF, but other applications do not. The
Cache Manager will also ask to set the EOF (in a “never truncate” format)
but this call is (oddly enough) ignored by FAT and NTFS (they instead rely
upon their own sense of the size of the file).

Thus, if you retrieve the file size information before the write, it would
be 25 bytes. After the write it would be 4325. Of course, you can confirm
this by merely trying it.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Scott Elliott [mailto:scottel@us.ibm.com]
Sent: Thursday, April 11, 2002 2:08 PM
To: File Systems Developers
Subject: [ntfsd] RE: FsContext - does it come back null?

I am filtering all files in a certain directory on a hard drive.
Currently I’m working on Win2k FAT. However, I hoping for support on
WinNT4.0/Win2k/WinXP for both NTFS and FAT (no other file systems will be
suported).

While I’m at it, I have another question. Is the file size set before
data is written to the file. For example: Start with Test.txt, size 25
bytes. Write 4300 more bytes to Test.txt. When is the size of Test.txt
set to 4325? Before the write or after the write?

Thanks!!
Scott

What are you filtering? What version of the OS? There are some cases *I*
know about here but they are specific to version/file systems.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Scott Elliott [mailto:scottel@us.ibm.com]
Sent: Thursday, April 11, 2002 1:22 PM
To: File Systems Developers
Subject: [ntfsd] FsContext - does it come back null?

I have a question concerning the FsContext field of the file object. I
understand that only one FsContext exists for each open file, no matter
how many applications open it. I also know that the file system doesn’t
close or release or whatever, the FsContext pointer until the last
reference to the file is closed. The question I have is this: If I am
tracking a particular FsContext, will that pointer be NULL in the
completion routine for IRP_MJ_CLOSE in my filter driver for the last
reference to the file? I seem to be faced with an FsContext pointing to
one file initially and then later pointing to another file. This is
causing me to decrypt data that wasn’t encrypted! Bad News! Can an
FsContext point to one file and then another without my filter driver’s
knowledge or am I chasing a bug in my FsContext tracking code?

Thanks,
Scott


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

Tony,

Where can I read Pete’s point about reference counting?

For the file size issue:
Is it acceptable to send the data, get the file size
(IRP_MJ_QUERY_INFORMATION), then resend the data based on that file size?
I’m still unclear how the file system can determine what to set the actual
file size when the length + offset in the parameter field is almost always
not the actual file size. Can you elaborate some on this?

Thanks,
Scott

Scott,

I know of no problems using FAT or NTFS on Windows 2K when tracking the
FsContext value (that is, it doesn’t “change” in the fashion you described).
Pete’s point about the reference counting is valid, although this is much
more an issue when filtering NTFS than when filtering FAT. Thus, this
sounds like it is most likely a bug in your own tracking/reference counting
code.

The file size is set by the user-level write operation. Some user
applications also call and set the EOF, but other applications do not. The
Cache Manager will also ask to set the EOF (in a “never truncate” format)
but this call is (oddly enough) ignored by FAT and NTFS (they instead rely
upon their own sense of the size of the file).

Thus, if you retrieve the file size information before the write, it would
be 25 bytes. After the write it would be 4325. Of course, you can confirm
this by merely trying it.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Scott Elliott [mailto:scottel@us.ibm.com]
Sent: Thursday, April 11, 2002 2:08 PM
To: File Systems Developers
Subject: [ntfsd] RE: FsContext - does it come back null?

I am filtering all files in a certain directory on a hard drive.
Currently I’m working on Win2k FAT. However, I hoping for support on
WinNT4.0/Win2k/WinXP for both NTFS and FAT (no other file systems will be
suported).

While I’m at it, I have another question. Is the file size set before
data is written to the file. For example: Start with Test.txt, size 25
bytes. Write 4300 more bytes to Test.txt. When is the size of Test.txt
set to 4325? Before the write or after the write?

Thanks!!
Scott

> What are you filtering? What version of the OS? There are some cases *I*
> know about here but they are specific to version/file systems.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: Scott Elliott [mailto:scottel@us.ibm.com]
> Sent: Thursday, April 11, 2002 1:22 PM
> To: File Systems Developers
> Subject: [ntfsd] FsContext - does it come back null?
>
> I have a question concerning the FsContext field of the file object. I
> understand that only one FsContext exists for each open file, no matter
> how many applications open it. I also know that the file system doesn’t
> close or release or whatever, the FsContext pointer until the last
> reference to the file is closed. The question I have is this: If I am
> tracking a particular FsContext, will that pointer be NULL in the
> completion routine for IRP_MJ_CLOSE in my filter driver for the last
> reference to the file? I seem to be faced with an FsContext pointing to
> one file initially and then later pointing to another file. This is
> causing me to decrypt data that wasn’t encrypted! Bad News! Can an
> FsContext point to one file and then another without my filter driver’s
> knowledge or am I chasing a bug in my FsContext tracking code?
>
> Thanks,
> Scott
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

> reference to the file? I seem to be faced with an FsContext pointing to

one file initially and then later pointing to another file. This is

Amazing. Maybe this can be a reality due to some buggy FS filter.
FsContext points to FCB, it is set inside the FSD’s CREATE path and is not changed till CLOSE.

Max

> bytes. Write 4300 more bytes to Test.txt. When is the size of Test.txt

set to 4325? Before the write or after the write?

Inside the FSD’s write path. For your filter, write and size increment are one atomic operation.

Max

Hi Tony,
Regarding the FsContect tracking, I experienced that its value changed so
often for a file in a redirector client. For example, I tracked the
FsContext in the open, and another file opened with the same FsContext
value, at that moment I overwrote the first entry with this one. However,
the first file subsequently arrived in different FsContext, since I already
overwrote its entry, I have to do its initialization again. The initialize
process is expensive since it requires to read the file. Is there a better
way to do this tracking? How long do I need to maintain the entry in my hash
table, until the same FsContext with a different filename??

Hope to hear about any suggestion.

Thank you,
Sin-Lam

Scott,

I know of no problems using FAT or NTFS on Windows 2K when tracking the
FsContext value (that is, it doesn’t “change” in the fashion you
described).
Pete’s point about the reference counting is valid, although this is much
more an issue when filtering NTFS than when filtering FAT. Thus, this
sounds like it is most likely a bug in your own tracking/reference
counting
code.

The file size is set by the user-level write operation. Some user
applications also call and set the EOF, but other applications do not.
The
Cache Manager will also ask to set the EOF (in a “never truncate” format)
but this call is (oddly enough) ignored by FAT and NTFS (they instead rely
upon their own sense of the size of the file).

Thus, if you retrieve the file size information before the write, it would
be 25 bytes. After the write it would be 4325. Of course, you can
confirm
this by merely trying it.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Scott Elliott [mailto:scottel@us.ibm.com]
Sent: Thursday, April 11, 2002 2:08 PM
To: File Systems Developers
Subject: [ntfsd] RE: FsContext - does it come back null?

I am filtering all files in a certain directory on a hard drive.
Currently I’m working on Win2k FAT. However, I hoping for support on
WinNT4.0/Win2k/WinXP for both NTFS and FAT (no other file systems will be
suported).

While I’m at it, I have another question. Is the file size set before
data is written to the file. For example: Start with Test.txt, size 25
bytes. Write 4300 more bytes to Test.txt. When is the size of Test.txt
set to 4325? Before the write or after the write?

Thanks!!
Scott

> What are you filtering? What version of the OS? There are some cases
*I*
> know about here but they are specific to version/file systems.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: Scott Elliott [mailto:scottel@us.ibm.com]
> Sent: Thursday, April 11, 2002 1:22 PM
> To: File Systems Developers
> Subject: [ntfsd] FsContext - does it come back null?
>
> I have a question concerning the FsContext field of the file object. I
> understand that only one FsContext exists for each open file, no matter
> how many applications open it. I also know that the file system doesn’t
> close or release or whatever, the FsContext pointer until the last
> reference to the file is closed. The question I have is this: If I am
> tracking a particular FsContext, will that pointer be NULL in the
> completion routine for IRP_MJ_CLOSE in my filter driver for the last
> reference to the file? I seem to be faced with an FsContext pointing to
> one file initially and then later pointing to another file. This is
> causing me to decrypt data that wasn’t encrypted! Bad News! Can an
> FsContext point to one file and then another without my filter driver’s
> knowledge or am I chasing a bug in my FsContext tracking code?
>
> Thanks,
> Scott
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntfsd as: xxxxx@lit.org.sg
To unsubscribe send a blank email to %%email.unsub%%

Sin-Lam:

What version of Windows are you using for development?

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Tan Sin Lam [mailto:xxxxx@lit.org.sg]
Sent: Saturday, April 13, 2002 2:07 AM
To: File Systems Developers
Subject: [ntfsd] RE: FsContext - does it come back null?

Hi Tony,
Regarding the FsContect tracking, I experienced that its value changed so
often for a file in a redirector client. For example, I tracked the
FsContext in the open, and another file opened with the same FsContext
value, at that moment I overwrote the first entry with this one. However,
the first file subsequently arrived in different FsContext, since I already
overwrote its entry, I have to do its initialization again. The initialize
process is expensive since it requires to read the file. Is there a better
way to do this tracking? How long do I need to maintain the entry in my hash
table, until the same FsContext with a different filename??

Hope to hear about any suggestion.

Thank you,
Sin-Lam

Scott,

I know of no problems using FAT or NTFS on Windows 2K when tracking the
FsContext value (that is, it doesn’t “change” in the fashion you
described).
Pete’s point about the reference counting is valid, although this is much
more an issue when filtering NTFS than when filtering FAT. Thus, this
sounds like it is most likely a bug in your own tracking/reference
counting
code.

The file size is set by the user-level write operation. Some user
applications also call and set the EOF, but other applications do not.
The
Cache Manager will also ask to set the EOF (in a “never truncate” format)
but this call is (oddly enough) ignored by FAT and NTFS (they instead rely
upon their own sense of the size of the file).

Thus, if you retrieve the file size information before the write, it would
be 25 bytes. After the write it would be 4325. Of course, you can
confirm
this by merely trying it.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Scott Elliott [mailto:scottel@us.ibm.com]
Sent: Thursday, April 11, 2002 2:08 PM
To: File Systems Developers
Subject: [ntfsd] RE: FsContext - does it come back null?

I am filtering all files in a certain directory on a hard drive.
Currently I’m working on Win2k FAT. However, I hoping for support on
WinNT4.0/Win2k/WinXP for both NTFS and FAT (no other file systems will be
suported).

While I’m at it, I have another question. Is the file size set before
data is written to the file. For example: Start with Test.txt, size 25
bytes. Write 4300 more bytes to Test.txt. When is the size of Test.txt
set to 4325? Before the write or after the write?

Thanks!!
Scott

> What are you filtering? What version of the OS? There are some cases
*I*
> know about here but they are specific to version/file systems.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: Scott Elliott [mailto:scottel@us.ibm.com]
> Sent: Thursday, April 11, 2002 1:22 PM
> To: File Systems Developers
> Subject: [ntfsd] FsContext - does it come back null?
>
> I have a question concerning the FsContext field of the file object. I
> understand that only one FsContext exists for each open file, no matter
> how many applications open it. I also know that the file system doesn’t
> close or release or whatever, the FsContext pointer until the last
> reference to the file is closed. The question I have is this: If I am
> tracking a particular FsContext, will that pointer be NULL in the
> completion routine for IRP_MJ_CLOSE in my filter driver for the last
> reference to the file? I seem to be faced with an FsContext pointing to
> one file initially and then later pointing to another file. This is
> causing me to decrypt data that wasn’t encrypted! Bad News! Can an
> FsContext point to one file and then another without my filter driver’s
> knowledge or am I chasing a bug in my FsContext tracking code?
>
> Thanks,
> Scott
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntfsd as: xxxxx@lit.org.sg
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

Hi Tony,
I am using Win 2k SP2 for both Redirector and Srv. Later I plan to support
Win XP too.
Thanks for any info!

Regards,
Sin-Lam

----- Original Message -----
From: “Tony Mason”
To: “File Systems Developers”
Sent: Monday, April 15, 2002 8:08 AM
Subject: [ntfsd] RE: FsContext - does it come back null?

> Sin-Lam:
>
> What version of Windows are you using for development?
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: Tan Sin Lam [mailto:xxxxx@lit.org.sg]
> Sent: Saturday, April 13, 2002 2:07 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: FsContext - does it come back null?
>
> Hi Tony,
> Regarding the FsContect tracking, I experienced that its value changed
so
> often for a file in a redirector client. For example, I tracked the
> FsContext in the open, and another file opened with the same FsContext
> value, at that moment I overwrote the first entry with this one. However,
> the first file subsequently arrived in different FsContext, since I
already
> overwrote its entry, I have to do its initialization again. The initialize
> process is expensive since it requires to read the file. Is there a better
> way to do this tracking? How long do I need to maintain the entry in my
hash
> table, until the same FsContext with a different filename??
>
> Hope to hear about any suggestion.
>
> Thank you,
> Sin-Lam
>
> > Scott,
> >
> > I know of no problems using FAT or NTFS on Windows 2K when tracking the
> > FsContext value (that is, it doesn’t “change” in the fashion you
> described).
> > Pete’s point about the reference counting is valid, although this is
much
> > more an issue when filtering NTFS than when filtering FAT. Thus, this
> > sounds like it is most likely a bug in your own tracking/reference
> counting
> > code.
> >
> > The file size is set by the user-level write operation. Some user
> > applications also call and set the EOF, but other applications do not.
> The
> > Cache Manager will also ask to set the EOF (in a “never truncate”
format)
> > but this call is (oddly enough) ignored by FAT and NTFS (they instead
rely
> > upon their own sense of the size of the file).
> >
> > Thus, if you retrieve the file size information before the write, it
would
> > be 25 bytes. After the write it would be 4325. Of course, you can
> confirm
> > this by merely trying it.
> >
> > Regards,
> >
> > Tony
> >
> > Tony Mason
> > Consulting Partner
> > OSR Open Systems Resources, Inc.
> > http://www.osr.com
> >
> >
> > -----Original Message-----
> > From: Scott Elliott [mailto:scottel@us.ibm.com]
> > Sent: Thursday, April 11, 2002 2:08 PM
> > To: File Systems Developers
> > Subject: [ntfsd] RE: FsContext - does it come back null?
> >
> > I am filtering all files in a certain directory on a hard drive.
> > Currently I’m working on Win2k FAT. However, I hoping for support on
> > WinNT4.0/Win2k/WinXP for both NTFS and FAT (no other file systems will
be
> > suported).
> >
> > While I’m at it, I have another question. Is the file size set before
> > data is written to the file. For example: Start with Test.txt, size 25
> > bytes. Write 4300 more bytes to Test.txt. When is the size of Test.txt
> > set to 4325? Before the write or after the write?
> >
> > Thanks!!
> > Scott
> >
> > > What are you filtering? What version of the OS? There are some cases
> I
> > > know about here but they are specific to version/file systems.
> > >
> > > Regards,
> > >
> > > Tony
> > >
> > > Tony Mason
> > > Consulting Partner
> > > OSR Open Systems Resources, Inc.
> > > http://www.osr.com
> > >
> > >
> > > -----Original Message-----
> > > From: Scott Elliott [mailto:scottel@us.ibm.com]
> > > Sent: Thursday, April 11, 2002 1:22 PM
> > > To: File Systems Developers
> > > Subject: [ntfsd] FsContext - does it come back null?
> > >
> > > I have a question concerning the FsContext field of the file object.
I
> > > understand that only one FsContext exists for each open file, no
matter
> > > how many applications open it. I also know that the file system
doesn’t
> > > close or release or whatever, the FsContext pointer until the last
> > > reference to the file is closed. The question I have is this: If I
am
> > > tracking a particular FsContext, will that pointer be NULL in the
> > > completion routine for IRP_MJ_CLOSE in my filter driver for the last
> > > reference to the file? I seem to be faced with an FsContext pointing
to
> > > one file initially and then later pointing to another file. This is
> > > causing me to decrypt data that wasn’t encrypted! Bad News! Can an
> > > FsContext point to one file and then another without my filter
driver’s
> > > knowledge or am I chasing a bug in my FsContext tracking code?
> > >
> > > Thanks,
> > > Scott
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@osr.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@osr.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@lit.org.sg
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntfsd as: xxxxx@lit.org.sg
> To unsubscribe send a blank email to %%email.unsub%%
>

Sin-Lam:

Hmm. I recall observing this in NT 4.0, but not in W2K, which is why I
asked.

At any rate, the “trick” we used when first handling this problem is to look
at the FsContext value in the completion routine and, if it had changed,
update our tracking information. I suspect that what you will find then is
that you’ll observe when this state change occurs so you do not discard the
information prematurely.

I hope this helps.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Hope to see you at the next OSR file systems class October 7, 2002!

-----Original Message-----
From: Tan Sin Lam [mailto:xxxxx@lit.org.sg]
Sent: Monday, April 15, 2002 1:55 AM
To: File Systems Developers
Subject: [ntfsd] RE: FsContext - does it come back null?

Hi Tony,
I am using Win 2k SP2 for both Redirector and Srv. Later I plan to support
Win XP too.
Thanks for any info!

Regards,
Sin-Lam

----- Original Message -----
From: “Tony Mason”
To: “File Systems Developers”
Sent: Monday, April 15, 2002 8:08 AM
Subject: [ntfsd] RE: FsContext - does it come back null?

> Sin-Lam:
>
> What version of Windows are you using for development?
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: Tan Sin Lam [mailto:xxxxx@lit.org.sg]
> Sent: Saturday, April 13, 2002 2:07 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: FsContext - does it come back null?
>
> Hi Tony,
> Regarding the FsContect tracking, I experienced that its value changed
so
> often for a file in a redirector client. For example, I tracked the
> FsContext in the open, and another file opened with the same FsContext
> value, at that moment I overwrote the first entry with this one. However,
> the first file subsequently arrived in different FsContext, since I
already
> overwrote its entry, I have to do its initialization again. The initialize
> process is expensive since it requires to read the file. Is there a better
> way to do this tracking? How long do I need to maintain the entry in my
hash
> table, until the same FsContext with a different filename??
>
> Hope to hear about any suggestion.
>
> Thank you,
> Sin-Lam
>
> > Scott,
> >
> > I know of no problems using FAT or NTFS on Windows 2K when tracking the
> > FsContext value (that is, it doesn’t “change” in the fashion you
> described).
> > Pete’s point about the reference counting is valid, although this is
much
> > more an issue when filtering NTFS than when filtering FAT. Thus, this
> > sounds like it is most likely a bug in your own tracking/reference
> counting
> > code.
> >
> > The file size is set by the user-level write operation. Some user
> > applications also call and set the EOF, but other applications do not.
> The
> > Cache Manager will also ask to set the EOF (in a “never truncate”
format)
> > but this call is (oddly enough) ignored by FAT and NTFS (they instead
rely
> > upon their own sense of the size of the file).
> >
> > Thus, if you retrieve the file size information before the write, it
would
> > be 25 bytes. After the write it would be 4325. Of course, you can
> confirm
> > this by merely trying it.
> >
> > Regards,
> >
> > Tony
> >
> > Tony Mason
> > Consulting Partner
> > OSR Open Systems Resources, Inc.
> > http://www.osr.com
> >
> >
> > -----Original Message-----
> > From: Scott Elliott [mailto:scottel@us.ibm.com]
> > Sent: Thursday, April 11, 2002 2:08 PM
> > To: File Systems Developers
> > Subject: [ntfsd] RE: FsContext - does it come back null?
> >
> > I am filtering all files in a certain directory on a hard drive.
> > Currently I’m working on Win2k FAT. However, I hoping for support on
> > WinNT4.0/Win2k/WinXP for both NTFS and FAT (no other file systems will
be
> > suported).
> >
> > While I’m at it, I have another question. Is the file size set before
> > data is written to the file. For example: Start with Test.txt, size 25
> > bytes. Write 4300 more bytes to Test.txt. When is the size of Test.txt
> > set to 4325? Before the write or after the write?
> >
> > Thanks!!
> > Scott
> >
> > > What are you filtering? What version of the OS? There are some cases
> I
> > > know about here but they are specific to version/file systems.
> > >
> > > Regards,
> > >
> > > Tony
> > >
> > > Tony Mason
> > > Consulting Partner
> > > OSR Open Systems Resources, Inc.
> > > http://www.osr.com
> > >
> > >
> > > -----Original Message-----
> > > From: Scott Elliott [mailto:scottel@us.ibm.com]
> > > Sent: Thursday, April 11, 2002 1:22 PM
> > > To: File Systems Developers
> > > Subject: [ntfsd] FsContext - does it come back null?
> > >
> > > I have a question concerning the FsContext field of the file object.
I
> > > understand that only one FsContext exists for each open file, no
matter
> > > how many applications open it. I also know that the file system
doesn’t
> > > close or release or whatever, the FsContext pointer until the last
> > > reference to the file is closed. The question I have is this: If I
am
> > > tracking a particular FsContext, will that pointer be NULL in the
> > > completion routine for IRP_MJ_CLOSE in my filter driver for the last
> > > reference to the file? I seem to be faced with an FsContext pointing
to
> > > one file initially and then later pointing to another file. This is
> > > causing me to decrypt data that wasn’t encrypted! Bad News! Can an
> > > FsContext point to one file and then another without my filter
driver’s
> > > knowledge or am I chasing a bug in my FsContext tracking code?
> > >
> > > Thanks,
> > > Scott
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@osr.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@osr.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@lit.org.sg
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntfsd as: xxxxx@lit.org.sg
> To unsubscribe send a blank email to %%email.unsub%%
>


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

Sin-Lam,

I talked with the redirector developers about this issue and the
redirector never changes the value in the FSContext field after it is
created (this is for Win2K and later).

I am guessing that you are either missing an IRP_MJ_CLOSE (because the
same FSContext address can be reused on a different file after a close)
or your filter or another filter is accidentally changing the FSContext
value (perhaps using a single equal instead of a double equal).

You need to do some more investigation on exactly what you are seeing
and give some more detailed information.

Neal Christiansen

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Monday, April 15, 2002 07:33 AM
To: File Systems Developers
Subject: [ntfsd] RE: FsContext - does it come back null?

Sin-Lam:

Hmm. I recall observing this in NT 4.0, but not in W2K, which is why I
asked.

At any rate, the “trick” we used when first handling this problem is to
look
at the FsContext value in the completion routine and, if it had changed,
update our tracking information. I suspect that what you will find then
is
that you’ll observe when this state change occurs so you do not discard
the
information prematurely.

I hope this helps.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Hope to see you at the next OSR file systems class October 7, 2002!

-----Original Message-----
From: Tan Sin Lam [mailto:xxxxx@lit.org.sg]
Sent: Monday, April 15, 2002 1:55 AM
To: File Systems Developers
Subject: [ntfsd] RE: FsContext - does it come back null?

Hi Tony,
I am using Win 2k SP2 for both Redirector and Srv. Later I plan to
support
Win XP too.
Thanks for any info!

Regards,
Sin-Lam

----- Original Message -----
From: “Tony Mason”
To: “File Systems Developers”
Sent: Monday, April 15, 2002 8:08 AM
Subject: [ntfsd] RE: FsContext - does it come back null?

> Sin-Lam:
>
> What version of Windows are you using for development?
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: Tan Sin Lam [mailto:xxxxx@lit.org.sg]
> Sent: Saturday, April 13, 2002 2:07 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: FsContext - does it come back null?
>
> Hi Tony,
> Regarding the FsContect tracking, I experienced that its value
changed
so
> often for a file in a redirector client. For example, I tracked the
> FsContext in the open, and another file opened with the same FsContext
> value, at that moment I overwrote the first entry with this one.
However,
> the first file subsequently arrived in different FsContext, since I
already
> overwrote its entry, I have to do its initialization again. The
initialize
> process is expensive since it requires to read the file. Is there a
better
> way to do this tracking? How long do I need to maintain the entry in
my
hash
> table, until the same FsContext with a different filename??
>
> Hope to hear about any suggestion.
>
> Thank you,
> Sin-Lam
>
> > Scott,
> >
> > I know of no problems using FAT or NTFS on Windows 2K when tracking
the
> > FsContext value (that is, it doesn’t “change” in the fashion you
> described).
> > Pete’s point about the reference counting is valid, although this is
much
> > more an issue when filtering NTFS than when filtering FAT. Thus,
this
> > sounds like it is most likely a bug in your own tracking/reference
> counting
> > code.
> >
> > The file size is set by the user-level write operation. Some user
> > applications also call and set the EOF, but other applications do
not.
> The
> > Cache Manager will also ask to set the EOF (in a “never truncate”
format)
> > but this call is (oddly enough) ignored by FAT and NTFS (they
instead
rely
> > upon their own sense of the size of the file).
> >
> > Thus, if you retrieve the file size information before the write, it
would
> > be 25 bytes. After the write it would be 4325. Of course, you can
> confirm
> > this by merely trying it.
> >
> > Regards,
> >
> > Tony
> >
> > Tony Mason
> > Consulting Partner
> > OSR Open Systems Resources, Inc.
> > http://www.osr.com
> >
> >
> > -----Original Message-----
> > From: Scott Elliott [mailto:scottel@us.ibm.com]
> > Sent: Thursday, April 11, 2002 2:08 PM
> > To: File Systems Developers
> > Subject: [ntfsd] RE: FsContext - does it come back null?
> >
> > I am filtering all files in a certain directory on a hard drive.
> > Currently I’m working on Win2k FAT. However, I hoping for support
on
> > WinNT4.0/Win2k/WinXP for both NTFS and FAT (no other file systems
will
be
> > suported).
> >
> > While I’m at it, I have another question. Is the file size set
before
> > data is written to the file. For example: Start with Test.txt,
size 25
> > bytes. Write 4300 more bytes to Test.txt. When is the size of
Test.txt
> > set to 4325? Before the write or after the write?
> >
> > Thanks!!
> > Scott
> >
> > > What are you filtering? What version of the OS? There are some
cases
> I
> > > know about here but they are specific to version/file systems.
> > >
> > > Regards,
> > >
> > > Tony
> > >
> > > Tony Mason
> > > Consulting Partner
> > > OSR Open Systems Resources, Inc.
> > > http://www.osr.com
> > >
> > >
> > > -----Original Message-----
> > > From: Scott Elliott [mailto:scottel@us.ibm.com]
> > > Sent: Thursday, April 11, 2002 1:22 PM
> > > To: File Systems Developers
> > > Subject: [ntfsd] FsContext - does it come back null?
> > >
> > > I have a question concerning the FsContext field of the file
object.
I
> > > understand that only one FsContext exists for each open file, no
matter
> > > how many applications open it. I also know that the file system
doesn’t
> > > close or release or whatever, the FsContext pointer until the last
> > > reference to the file is closed. The question I have is this: If
I
am
> > > tracking a particular FsContext, will that pointer be NULL in the
> > > completion routine for IRP_MJ_CLOSE in my filter driver for the
last
> > > reference to the file? I seem to be faced with an FsContext
pointing
to
> > > one file initially and then later pointing to another file. This
is
> > > causing me to decrypt data that wasn’t encrypted! Bad News! Can
an
> > > FsContext point to one file and then another without my filter
driver’s
> > > knowledge or am I chasing a bug in my FsContext tracking code?
> > >
> > > Thanks,
> > > Scott
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@osr.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@osr.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@lit.org.sg
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntfsd as: xxxxx@lit.org.sg
> To unsubscribe send a blank email to %%email.unsub%%
>


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntfsd as: xxxxx@Windows.Microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

Hi Tony & Neal,
Thanks for the information. My apology, I reread my previous message
again and
found that I didn’t explain it well and caused confusion. I think my problem
is more on the
implementation issue instead of file system. I didn’t keep track of
FsContext on close completion and only track the FsContext value during the
create completion.

Indeed, the redirector never changes the value in the FsContext field
after it is
created. When it is closed and reopened again after a few file system calls,
it can arrive in different FsContext value. At that moment, the original
FsContext has been
overwritten by a different file, thus my hash entry for the original file is
deallocated too.

When the original file is opened again with different FsContext, I need to
do the hash entry initialization again, which require the driver to open the
file and read the header information. I tried to avoid reading this header
information again.
The FsContext value in the network file changed more often than the local
drives, that is
why I am curious if there is a better approach to keep the hash table
updated.

Anyway, I appreciate these helpful information.

Regards,
Sin-Lam

----- Original Message -----
From: “Neal Christiansen”
To: “File Systems Developers”
Sent: Tuesday, April 16, 2002 1:36 AM
Subject: [ntfsd] RE: FsContext - does it come back null?

Sin-Lam,

I talked with the redirector developers about this issue and the
redirector never changes the value in the FSContext field after it is
created (this is for Win2K and later).

I am guessing that you are either missing an IRP_MJ_CLOSE (because the
same FSContext address can be reused on a different file after a close)
or your filter or another filter is accidentally changing the FSContext
value (perhaps using a single equal instead of a double equal).

You need to do some more investigation on exactly what you are seeing
and give some more detailed information.

Neal Christiansen

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Monday, April 15, 2002 07:33 AM
To: File Systems Developers
Subject: [ntfsd] RE: FsContext - does it come back null?

Sin-Lam:

Hmm. I recall observing this in NT 4.0, but not in W2K, which is why I
asked.

At any rate, the “trick” we used when first handling this problem is to
look
at the FsContext value in the completion routine and, if it had changed,
update our tracking information. I suspect that what you will find then
is
that you’ll observe when this state change occurs so you do not discard
the
information prematurely.

I hope this helps.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Hope to see you at the next OSR file systems class October 7, 2002!

-----Original Message-----
From: Tan Sin Lam [mailto:xxxxx@lit.org.sg]
Sent: Monday, April 15, 2002 1:55 AM
To: File Systems Developers
Subject: [ntfsd] RE: FsContext - does it come back null?

Hi Tony,
I am using Win 2k SP2 for both Redirector and Srv. Later I plan to
support
Win XP too.
Thanks for any info!

Regards,
Sin-Lam

----- Original Message -----
From: “Tony Mason”
To: “File Systems Developers”
Sent: Monday, April 15, 2002 8:08 AM
Subject: [ntfsd] RE: FsContext - does it come back null?

> Sin-Lam:
>
> What version of Windows are you using for development?
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: Tan Sin Lam [mailto:xxxxx@lit.org.sg]
> Sent: Saturday, April 13, 2002 2:07 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: FsContext - does it come back null?
>
> Hi Tony,
> Regarding the FsContect tracking, I experienced that its value
changed
so
> often for a file in a redirector client. For example, I tracked the
> FsContext in the open, and another file opened with the same FsContext
> value, at that moment I overwrote the first entry with this one.
However,
> the first file subsequently arrived in different FsContext, since I
already
> overwrote its entry, I have to do its initialization again. The
initialize
> process is expensive since it requires to read the file. Is there a
better
> way to do this tracking? How long do I need to maintain the entry in
my
hash
> table, until the same FsContext with a different filename??
>
> Hope to hear about any suggestion.
>
> Thank you,
> Sin-Lam
>
> > Scott,
> >
> > I know of no problems using FAT or NTFS on Windows 2K when tracking
the
> > FsContext value (that is, it doesn’t “change” in the fashion you
> described).
> > Pete’s point about the reference counting is valid, although this is
much
> > more an issue when filtering NTFS than when filtering FAT. Thus,
this
> > sounds like it is most likely a bug in your own tracking/reference
> counting
> > code.
> >
> > The file size is set by the user-level write operation. Some user
> > applications also call and set the EOF, but other applications do
not.
> The
> > Cache Manager will also ask to set the EOF (in a “never truncate”
format)
> > but this call is (oddly enough) ignored by FAT and NTFS (they
instead
rely
> > upon their own sense of the size of the file).
> >
> > Thus, if you retrieve the file size information before the write, it
would
> > be 25 bytes. After the write it would be 4325. Of course, you can
> confirm
> > this by merely trying it.
> >
> > Regards,
> >
> > Tony
> >
> > Tony Mason
> > Consulting Partner
> > OSR Open Systems Resources, Inc.
> > http://www.osr.com
> >
> >
> > -----Original Message-----
> > From: Scott Elliott [mailto:scottel@us.ibm.com]
> > Sent: Thursday, April 11, 2002 2:08 PM
> > To: File Systems Developers
> > Subject: [ntfsd] RE: FsContext - does it come back null?
> >
> > I am filtering all files in a certain directory on a hard drive.
> > Currently I’m working on Win2k FAT. However, I hoping for support
on
> > WinNT4.0/Win2k/WinXP for both NTFS and FAT (no other file systems
will
be
> > suported).
> >
> > While I’m at it, I have another question. Is the file size set
before
> > data is written to the file. For example: Start with Test.txt,
size 25
> > bytes. Write 4300 more bytes to Test.txt. When is the size of
Test.txt
> > set to 4325? Before the write or after the write?
> >
> > Thanks!!
> > Scott
> >
> > > What are you filtering? What version of the OS? There are some
cases
> I
> > > know about here but they are specific to version/file systems.
> > >
> > > Regards,
> > >
> > > Tony
> > >
> > > Tony Mason
> > > Consulting Partner
> > > OSR Open Systems Resources, Inc.
> > > http://www.osr.com
> > >
> > >
> > > -----Original Message-----
> > > From: Scott Elliott [mailto:scottel@us.ibm.com]
> > > Sent: Thursday, April 11, 2002 1:22 PM
> > > To: File Systems Developers
> > > Subject: [ntfsd] FsContext - does it come back null?
> > >
> > > I have a question concerning the FsContext field of the file
object.
I
> > > understand that only one FsContext exists for each open file, no
matter
> > > how many applications open it. I also know that the file system
doesn’t
> > > close or release or whatever, the FsContext pointer until the last
> > > reference to the file is closed. The question I have is this: If
I
am
> > > tracking a particular FsContext, will that pointer be NULL in the
> > > completion routine for IRP_MJ_CLOSE in my filter driver for the
last
> > > reference to the file? I seem to be faced with an FsContext
pointing
to
> > > one file initially and then later pointing to another file. This
is
> > > causing me to decrypt data that wasn’t encrypted! Bad News! Can
an
> > > FsContext point to one file and then another without my filter
driver’s
> > > knowledge or am I chasing a bug in my FsContext tracking code?
> > >
> > > Thanks,
> > > Scott
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@osr.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@osr.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@lit.org.sg
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntfsd as: xxxxx@lit.org.sg
> To unsubscribe send a blank email to %%email.unsub%%
>


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntfsd as: xxxxx@Windows.Microsoft.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntfsd as: xxxxx@lit.org.sg
To unsubscribe send a blank email to %%email.unsub%%

How can I identify the remotely handled file operations using file mon vxd?
As these operations are handled
by kernel32. but there are file operations which kernel32 does for local
machine also as creating swap file…
I want to differentiate kernel32 operations as local / remote in file mon
vxd.

thanks
Shruti

----- Original Message -----
From: “Tan Sin Lam”
To: “File Systems Developers”
Sent: Tuesday, April 16, 2002 4:16 PM
Subject: [ntfsd] RE: FsContext - does it come back null?

> Hi Tony & Neal,
> Thanks for the information. My apology, I reread my previous message
> again and
> found that I didn’t explain it well and caused confusion. I think my
problem
> is more on the
> implementation issue instead of file system. I didn’t keep track of
> FsContext on close completion and only track the FsContext value during
the
> create completion.
>
> Indeed, the redirector never changes the value in the FsContext field
> after it is
> created. When it is closed and reopened again after a few file system
calls,
> it can arrive in different FsContext value. At that moment, the original
> FsContext has been
> overwritten by a different file, thus my hash entry for the original file
is
> deallocated too.
>
> When the original file is opened again with different FsContext, I need
to
> do the hash entry initialization again, which require the driver to open
the
> file and read the header information. I tried to avoid reading this header
> information again.
> The FsContext value in the network file changed more often than the local
> drives, that is
> why I am curious if there is a better approach to keep the hash table
> updated.
>
> Anyway, I appreciate these helpful information.
>
> Regards,
> Sin-Lam
>
> ----- Original Message -----
> From: “Neal Christiansen”
> To: “File Systems Developers”
> Sent: Tuesday, April 16, 2002 1:36 AM
> Subject: [ntfsd] RE: FsContext - does it come back null?
>
>
> Sin-Lam,
>
> I talked with the redirector developers about this issue and the
> redirector never changes the value in the FSContext field after it is
> created (this is for Win2K and later).
>
> I am guessing that you are either missing an IRP_MJ_CLOSE (because the
> same FSContext address can be reused on a different file after a close)
> or your filter or another filter is accidentally changing the FSContext
> value (perhaps using a single equal instead of a double equal).
>
> You need to do some more investigation on exactly what you are seeing
> and give some more detailed information.
>
> Neal Christiansen
>
> This posting is provided “AS IS” with no warranties, and confers no
> rights.
>
> -----Original Message-----
> From: Tony Mason [mailto:xxxxx@osr.com]
> Sent: Monday, April 15, 2002 07:33 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: FsContext - does it come back null?
>
> Sin-Lam:
>
> Hmm. I recall observing this in NT 4.0, but not in W2K, which is why I
> asked.
>
> At any rate, the “trick” we used when first handling this problem is to
> look
> at the FsContext value in the completion routine and, if it had changed,
> update our tracking information. I suspect that what you will find then
> is
> that you’ll observe when this state change occurs so you do not discard
> the
> information prematurely.
>
> I hope this helps.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Hope to see you at the next OSR file systems class October 7, 2002!
>
> -----Original Message-----
> From: Tan Sin Lam [mailto:xxxxx@lit.org.sg]
> Sent: Monday, April 15, 2002 1:55 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: FsContext - does it come back null?
>
> Hi Tony,
> I am using Win 2k SP2 for both Redirector and Srv. Later I plan to
> support
> Win XP too.
> Thanks for any info!
>
> Regards,
> Sin-Lam
>
> ----- Original Message -----
> From: “Tony Mason”
> To: “File Systems Developers”
> Sent: Monday, April 15, 2002 8:08 AM
> Subject: [ntfsd] RE: FsContext - does it come back null?
>
>
> > Sin-Lam:
> >
> > What version of Windows are you using for development?
> >
> > Regards,
> >
> > Tony
> >
> > Tony Mason
> > Consulting Partner
> > OSR Open Systems Resources, Inc.
> > http://www.osr.com
> >
> >
> > -----Original Message-----
> > From: Tan Sin Lam [mailto:xxxxx@lit.org.sg]
> > Sent: Saturday, April 13, 2002 2:07 AM
> > To: File Systems Developers
> > Subject: [ntfsd] RE: FsContext - does it come back null?
> >
> > Hi Tony,
> > Regarding the FsContect tracking, I experienced that its value
> changed
> so
> > often for a file in a redirector client. For example, I tracked the
> > FsContext in the open, and another file opened with the same FsContext
> > value, at that moment I overwrote the first entry with this one.
> However,
> > the first file subsequently arrived in different FsContext, since I
> already
> > overwrote its entry, I have to do its initialization again. The
> initialize
> > process is expensive since it requires to read the file. Is there a
> better
> > way to do this tracking? How long do I need to maintain the entry in
> my
> hash
> > table, until the same FsContext with a different filename??
> >
> > Hope to hear about any suggestion.
> >
> > Thank you,
> > Sin-Lam
> >
> > > Scott,
> > >
> > > I know of no problems using FAT or NTFS on Windows 2K when tracking
> the
> > > FsContext value (that is, it doesn’t “change” in the fashion you
> > described).
> > > Pete’s point about the reference counting is valid, although this is
> much
> > > more an issue when filtering NTFS than when filtering FAT. Thus,
> this
> > > sounds like it is most likely a bug in your own tracking/reference
> > counting
> > > code.
> > >
> > > The file size is set by the user-level write operation. Some user
> > > applications also call and set the EOF, but other applications do
> not.
> > The
> > > Cache Manager will also ask to set the EOF (in a “never truncate”
> format)
> > > but this call is (oddly enough) ignored by FAT and NTFS (they
> instead
> rely
> > > upon their own sense of the size of the file).
> > >
> > > Thus, if you retrieve the file size information before the write, it
> would
> > > be 25 bytes. After the write it would be 4325. Of course, you can
> > confirm
> > > this by merely trying it.
> > >
> > > Regards,
> > >
> > > Tony
> > >
> > > Tony Mason
> > > Consulting Partner
> > > OSR Open Systems Resources, Inc.
> > > http://www.osr.com
> > >
> > >
> > > -----Original Message-----
> > > From: Scott Elliott [mailto:scottel@us.ibm.com]
> > > Sent: Thursday, April 11, 2002 2:08 PM
> > > To: File Systems Developers
> > > Subject: [ntfsd] RE: FsContext - does it come back null?
> > >
> > > I am filtering all files in a certain directory on a hard drive.
> > > Currently I’m working on Win2k FAT. However, I hoping for support
> on
> > > WinNT4.0/Win2k/WinXP for both NTFS and FAT (no other file systems
> will
> be
> > > suported).
> > >
> > > While I’m at it, I have another question. Is the file size set
> before
> > > data is written to the file. For example: Start with Test.txt,
> size 25
> > > bytes. Write 4300 more bytes to Test.txt. When is the size of
> Test.txt
> > > set to 4325? Before the write or after the write?
> > >
> > > Thanks!!
> > > Scott
> > >
> > > > What are you filtering? What version of the OS? There are some
> cases
> > I
> > > > know about here but they are specific to version/file systems.
> > > >
> > > > Regards,
> > > >
> > > > Tony
> > > >
> > > > Tony Mason
> > > > Consulting Partner
> > > > OSR Open Systems Resources, Inc.
> > > > http://www.osr.com
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Scott Elliott [mailto:scottel@us.ibm.com]
> > > > Sent: Thursday, April 11, 2002 1:22 PM
> > > > To: File Systems Developers
> > > > Subject: [ntfsd] FsContext - does it come back null?
> > > >
> > > > I have a question concerning the FsContext field of the file
> object.
> I
> > > > understand that only one FsContext exists for each open file, no
> matter
> > > > how many applications open it. I also know that the file system
> doesn’t
> > > > close or release or whatever, the FsContext pointer until the last
> > > > reference to the file is closed. The question I have is this: If
> I
> am
> > > > tracking a particular FsContext, will that pointer be NULL in the
> > > > completion routine for IRP_MJ_CLOSE in my filter driver for the
> last
> > > > reference to the file? I seem to be faced with an FsContext
> pointing
> to
> > > > one file initially and then later pointing to another file. This
> is
> > > > causing me to decrypt data that wasn’t encrypted! Bad News! Can
> an
> > > > FsContext point to one file and then another without my filter
> driver’s
> > > > knowledge or am I chasing a bug in my FsContext tracking code?
> > > >
> > > > Thanks,
> > > > Scott
> > > >
> > > > —
> > > > You are currently subscribed to ntfsd as: xxxxx@osr.com
> > > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@osr.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@lit.org.sg
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@osr.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@lit.org.sg
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntfsd as: xxxxx@Windows.Microsoft.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntfsd as: xxxxx@lit.org.sg
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@mspl.net
> To unsubscribe send a blank email to %%email.unsub%%
>

> How can I identify the remotely handled file operations using file mon vxd?

As these operations are handled
by kernel32.

No, SRV talks to FSD directly, bypassing not only kernel32.dll, but even the kernel’s IO manager.

Max