This is why I always recommend that (if you choose to do it this way) you
understand the default locking algorithm - and IMPLEMENT it as necessary.
Most people on this list do not remember NT 3.51, but in that version, the
filter’s fast I/O entry points for this WERE called. Someone at Microsoft
changed the implementation of this in NT 4.0. In fact, Dfs (which was first
introduced in NT 4.0) would call the fast I/O entry point in the filter,
while the FsRtl library would call the file system. I used to comment on
this because it meant you had to handle the cases properly anyway (not a
problem for those of us used to NT 3.51).
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Nick Ryan [mailto:xxxxx@nryan.com]
Sent: Tuesday, June 17, 2003 2:14 PM
To: File Systems Developers
Subject: [ntfsd] RE: SyncTypeCreateSection equivalent for W2K
I’ve discovered that there is a VERY nasty bug that you may be
introducing by replacing the FSD’s AcquireFileForNtCreateSection
callback. Looking at the disassembly of FsRtlAcquireFileExclusive (on
Win2k since this is the relevant OS for this discussion), this function
first checks if there is an entry point for
AcquireFileForNtCreateSection in the FastIo dispatch table of the base
filesystem device object. If so, it calls it. If not, it takes the Main
resource in the FCB exclusive.
Now, for filesystems like NTFS that implement this callback, everything
is fine if your filter replaces the callback as long as it chains down.
However, for filesystems like FastFat that do NOT implement this
callback, you will be breaking the functionality of
FsRtlAcquireFileExclusive because you are making
FsRtlAcquireFileExclusive THINK that FastFat implements this callback.
It will thus not take the main resource, and the file will not be locked
in any way. Oops.
The first workaround that comes to mind is to take the main resource
yourself in the callback if the underlying filesystem did not have an
entry point.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Primoz Beltram
Sent: Tuesday, June 17, 2003 12:11 AM
To: File Systems Developers
Subject: [ntfsd] RE: SyncTypeCreateSection equivalent for W2K
Thank you Nick,
For my use cases, it is enough that I catch event when file
section is being created for the first time (#1). I would
like to “play it clean” and hook to ZwCreateSection only as
my last chance. With my debug-tracing (until now), I saw that
I can *relay* on SOP members (DataSectionObject,
ImageSectionObject, SharedCacheMap) being all NULL, to
distinguish that I have “SyncTypeCreateSection” type of
create_section_operation.
WBR Primoz
> -----Original Message-----
> From: Nick Ryan [mailto:xxxxx@nryan.com]
> Sent: Monday, June 16, 2003 9:48 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: SyncTypeCreateSection equivalent for W2K
>
>
> And for #2, even if this callback could be relied upon for
> determining section creation, as you say the problem remains
> of distinguishing calls for the purpose of creating a section
> from calls for other purposes (as in SyncTypeOther). For
> example, CcWriteBehind will invoke this callback via
> FsRtlAcquireFileExclusive before tearing down a stale shared
> cache map for a file.
>
> - Nick Ryan
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Nick Ryan
> > Sent: Monday, June 16, 2003 12:41 PM
> > To: File Systems Developers
> > Subject: [ntfsd] RE: SyncTypeCreateSection equivalent for W2K
> >
> >
> > Do you:
> >
> > 1. Need to know only when a file section is being created for the
> > purpose of a user-mode memory mapping?
> >
> > Or:
> >
> > 2. Need to know also when a file section is being created
when the
> > Cache Manager is initializing the cache?
> >
> > If #1, then you can feel secure hooking NtCreateSection call for
> > NT4/W2K, since the Cache Manager invokes MmCreateSection
directly.
> > And it is safe in my opinion since NT4 and W2K are stale
enough that
> > Microsoft is not going to be rewriting the kernel service table
> > dispatching code.
> >
> > If #2, then I think you need to find an alternative. The
> > AcquireFileForNtCreateSection does not appear to always
be invoked
> > when Cc creates the data object for a file during cache
buildup. At
> > least, Mm is making a decision inside MmCreateSection not
to do so
> > on my XP box (I haven’t explored exactly what it’s
checking to make
> > this decision).
> >
> > - Nick Ryan
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of
> Primoz Beltram
> > > Sent: Monday, June 16, 2003 2:45 AM
> > > To: File Systems Developers
> > > Subject: [ntfsd] SyncTypeCreateSection equivalent for W2K
> > >
> > >
> > > Hi all,
> > > In my (HSM) FSFD I have to do some write actions on offline file
> > > before it is exclusively locked by Mm. On WXP the
> > > PreAcquireForSectionSynchronization
> > > is the right point where I’m doing it. But I need to support
> > > W2K too (for a while :-)). On W2K I hooked my FSFD to file
> > > system FastIo AcquireFileForNtCreateSection function. I did
> > > this by following the suggestions from Mr. Ravisankar
> > > Pudipeddi, that he kindly posted to this mailing list a year
> > > ago and I’m getting calls for FastIo
> > > AcquireFileForNtCreateSection in my FSFD.
> > >
> > > The problem I have is:
> > > On WXP the PreAcquireForSectionSynchronization call is
> equipped with
> > > FS_FILTER_CALLBACK_DATA parameter and one of
> > its member
> > > (Parameters.AcquireForSectionSynchronization.SyncType) tells me
> > > that memory-mapped section of a file will be created,
as described
> > > in WXP-SP1 IFSKit documentation for
> > > FsRtlRegisterFileSystemFilterCallbacks. In all other calls to
> > > PreAcquireForSectionSynchronization on WXP, the
.SyncType is set
> > > to SyncTypeOther. What I’m searching for is how to figure out
> > > (PFILE_OBJECT parameter and THREAD is all I have), that FastIo
> > > AcquireFileForNtCreateSection on W2K is called for
> > > “SyncTypeCreateSection” type of
create_section_operation. I need
> > > to do write actions on a file only when memory-mapped
section of a
> > > file will be created (SyncTypeCreateSection on WXP).
> > >
> > > Can I figure it out from
> pFileObject->SectionObjectPointer members?
> > > Calling thread is not one of System threads? Can
> > > FSRTL_FLAG_USER_MAPPED_FILE flag from pFCB->Flags be of
> any help? Do
> > > the “dirty play” and hook ZwCreateSection native API call?
> > >
> > > Thanks in advance.
> > > WBR Primoz
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@nryan.com To
> > > unsubscribe send a blank email to
xxxxx@lists.osr.com
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@nryan.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@hermes.si To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com