Jump-start your project by learning from devs who
write Windows drivers and file systems every day.
Take an OSR seminar!

OSR is Hiring! Click here to find out more.

Upcoming OSR Seminars:
Windows Internals & Software Drivers Lab, Santa Clara, CA 5-9 August, 2013
Kernel Debugging & Crash Analysis for Windows Lab, Santa Clara, CA 9-13 September, 2013
Writing WDF Drivers for Windows Lab, Boston, MA 7-11 October, 2013
Developing File Systems for Windows, Seattle, WA 5-8 November, 2013

Go Back   OSR Online Lists > ntfsd
link Reparsing from a (successful) post-open?
Welcome, Guest
You must login to post to this list
  Message 1 of 11  
30 Jun 12 12:44
Dejan Maksimovic
xxxxxx@alfasp.com
Join Date: 18 Jul 2001
Posts To This List: 1448
Reparsing from a (successful) post-open?
Has anyone succeeded in doing this? In a successful post-open scenario, I am trying to cancel the file open, and reparse it: FltCancelFileOpen MyReplaceFileName (driver needs to run on XP, so I cannot use IoReplaceFileName) Data->IoStatus.Status = STATUS_REPARSE; Data->IoStatus.Information = IO_REPARSE; (tried with and without FltSetCallbackDataDirty at this point - neither works) In both cases, the calling application receives STATUS_FILE_CLOSED when it tries to access the file via the file object. I was under the impression that reparse from a post-open is possible, but I see no other way to make it work? (note that I am only trying to reparse from a successful post-OPEN, not create/replace) -- Kind regards, Dejan (MSN support: xxxxx@alfasp.com) http://www.alfasp.com File system audit, security and encryption kits.
  Message 2 of 11  
30 Jun 12 13:10
Alex Carp
xxxxxx@gmail.com
Join Date: 23 Feb 2010
Posts To This List: 800
RE: Reparsing from a (successful) post-open?
Hi Dejan, I guess that this happens because FltCancelFileOpen (and IoCancelFileOpen) will set the FO_FILE_OPEN_CANCELLED flag on the FILE_OBJECT (see my post on http://fsfilters.blogspot.com/2012/06/flags-of-fileobjects-part-iv.html) which is what leads to the behavior you're seeing. Also, FltCancelFileOpen (as well as IoCancelFileOpen) isn't restoring the FILE_OBJECT to the state it was in the preCallback, it simply performs some minimal steps and it's depending on the IO manager to do some more work once the operation returns to IopParseDevice (hence the usage of a flag in the FILE_OBJECT.. if the XxxCancelFileOpen APIs would completely revert the state of the FILE_OBJECT to the what it was before the file system sees the request there would be no need to signal that in the FILE_OBJECT...). I don't really know of a documented way of doing this and even though I've needed this type of behavior occasionally my approach has been to try to not let the original IRP_MJ_CREATE reach the file system when I thought there a possibility to reparse so that if I needed to take the reparse path I wouldn't have to cleanup an opened FILE_OBJECT. But perhaps someone else has had a different experience and can comment on your approach... Thanks, Alex.
  Message 3 of 11  
30 Jun 12 13:18
Dejan Maksimovic
xxxxxx@alfasp.com
Join Date: 18 Jul 2001
Posts To This List: 1448
Re: Reparsing from a (successful) post-open?
I was also under the exact same impression, and so anything that possibly needed a reparse would be handled in pre-Create. (I also saw, long time ago, that IoCancelFileOpn specifically said it is not possible to return STATUS_REPARSE after a file open is cancelled) However, I noticed some (old) posts saying they reparsed a successful file open, so it got me trying to do the same... because sometimes I need to check EVERYTHING in pre-Create for a reparse possibility, and since I need normalized file names, that hurts performance :( Open to other suggestions.. Regards, Dejan. Alex Carp wrote: > Hi Dejan, > > I guess that this happens because FltCancelFileOpen (and IoCancelFileOpen) > will set the FO_FILE_OPEN_CANCELLED flag on the FILE_OBJECT (see my post on > http://fsfilters.blogspot.com/2012/06/flags-of-fileobjects-part-iv.html) > which is what leads to the behavior you're seeing. Also, FltCancelFileOpen > (as well as IoCancelFileOpen) isn't restoring the FILE_OBJECT to the state > it was in the preCallback, it simply performs some minimal steps and it's > depending on the IO manager to do some more work once the operation returns > to IopParseDevice (hence the usage of a flag in the FILE_OBJECT.. if the <...excess quoted lines suppressed...> -- Kind regards, Dejan (MSN support: xxxxx@alfasp.com) http://www.alfasp.com File system audit, security and encryption kits.
  Message 4 of 11  
30 Jun 12 15:32
Daniel Terhell
xxxxxx@resplendence.com
Join Date: 14 Apr 2004
Posts To This List: 362
Re: Reparsing from a (successful) post-open?
The solution I think is doing a fake operation from pre-open just to see if the operation succeeds and then reparse if required. It might come with a performance penalty depending on what you are doing, but could this possibly not suit ? Does post the post operation give you any information wheter or not to decide to reparse or not, other than a success or failure ? The other other way round I think you would need to use a shadow file object for all subsequent operations on the file object which requires a lot more logic. //Daniel "Dejan Maksimovic" <xxxxx@alfasp.com> wrote in message news:94160@ntfsd... > > Has anyone succeeded in doing this? > In a successful post-open scenario, I am trying to cancel the file > open, and reparse it: > FltCancelFileOpen > MyReplaceFileName (driver needs to run on XP, so I cannot use > IoReplaceFileName) > Data->IoStatus.Status = STATUS_REPARSE; > Data->IoStatus.Information = IO_REPARSE; > (tried with and without FltSetCallbackDataDirty at this point - <...excess quoted lines suppressed...>
  Message 5 of 11  
30 Jun 12 18:04
Dejan Maksimovic
xxxxxx@alfasp.com
Join Date: 18 Jul 2001
Posts To This List: 1448
Re: Reparsing from a (successful) post-open?
The only thing I am trying to avoid is the query from pre-create, i.e. I want to do it in post-create. As I mentioned, there are cases where I might need to check every file on the system, and that means for every open attempt, I need to add another open attempt and always force a normalized name query - BOTH of which seem to cost more than a bloody regular open request itself :D Add to that the fact that we are most often deployed in environment with AHV V3 anti-virus, which has some extremely strange logic of having two filters - one extremely high on the stack, one extremely low. And if I issue an open request or a normalized file name request, the lowest one seems to add an additional open (which it sends to the top of the stack). So, just in case of normalized name query, with and without AHN V3, I see a performance penalty of >3x. Add a file open, and it's 10x. Note that I mean OVERALL system performance penalty! Not the open penalty itself, which sometimes goes 100x. (yes, sometimes, the latest and greatest hardware would take 1 full second to finish a file open - very often actually) Yes, yes, this is AHN's fault... by simple comparison of what happens with a minimalistic filter which only queries the normalized file name in pre-create and nothing else. But, unfortunately, an Antivirus, at fault or not, is a required component. If we can't work around it - it's bye bye.. So, I was hoping that I could offload this in post-create instead. xxxxx@resplendence.com wrote: > The solution I think is doing a fake operation from pre-open just to see if > the operation succeeds and then reparse if required. It might come with a > performance penalty depending on what you are doing, but could this possibly > not suit ? Does post the post operation give you any information wheter or > not to decide to reparse or not, other than a success or failure ? > > The other other way round I think you would need to use a shadow file object > for all subsequent operations on the file object which requires a lot more > logic. -- Kind regards, Dejan (MSN support: xxxxx@alfasp.com) http://www.alfasp.com File system audit, security and encryption kits.
  Message 6 of 11  
01 Jul 12 14:04
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 23 Feb 2000
Posts To This List: 3966
Re: Reparsing from a (successful) post-open?
> mentioned, there are cases where I might need to check every file on the system Try this: - no-op in PreCreate, allow Create to proceed - in PostCreate, do your checks (only if the things like desired access and a name do match, and checking the name in PostCreate should not be too slow). - if the checks fail (which is not a common case, so you can sacrifice the perf here) - then FltCreateFile your second "reparse target" file object, and then transfer all IRPs coming to the original file to this internal file of yours. Is this a solution? -- Maxim S. Shatskih Windows DDK MVP xxxxx@storagecraft.com http://www.storagecraft.com
  Message 7 of 11  
01 Jul 12 14:19
Dejan Maksimovic
xxxxxx@alfasp.com
Join Date: 18 Jul 2001
Posts To This List: 1448
Re: Reparsing from a (successful) post-open?
Hmm! Strangely, this might just work, and while we do a reverse of this... I never thought of using the opposite direction! Thanks.. I'll probably try it! "Maxim S. Shatskih" wrote: > > mentioned, there are cases where I might need to check every file on the system > > Try this: > > - no-op in PreCreate, allow Create to proceed > - in PostCreate, do your checks (only if the things like desired access and a name do match, and checking the name in PostCreate should not be too slow). > - if the checks fail (which is not a common case, so you can sacrifice the perf here) - then FltCreateFile your second "reparse target" file object, and then transfer all IRPs coming to the original file to this internal file of yours. > > Is this a solution? > <...excess quoted lines suppressed...> -- Kind regards, Dejan (MSN support: xxxxx@alfasp.com) http://www.alfasp.com File system audit, security and encryption kits.
  Message 8 of 11  
02 Jul 12 10:27
Dejan Maksimovic
xxxxxx@alfasp.com
Join Date: 18 Jul 2001
Posts To This List: 1448
Re: Reparsing from a (successful) post-open?
Nope :( We need to provide different data (from the reparsed version file). If we let the original open succeed, the data cache will be corrupted. Regards, Dejan. "Maxim S. Shatskih" wrote: > > mentioned, there are cases where I might need to check every file on the system > > Try this: > > - no-op in PreCreate, allow Create to proceed > - in PostCreate, do your checks (only if the things like desired access and a name do match, and checking the name in PostCreate should not be too slow). > - if the checks fail (which is not a common case, so you can sacrifice the perf here) - then FltCreateFile your second "reparse target" file object, and then transfer all IRPs coming to the original file to this internal file of yours. > > Is this a solution? > <...excess quoted lines suppressed...> -- Kind regards, Dejan (MSN support: xxxxx@alfasp.com) http://www.alfasp.com File system audit, security and encryption kits.
  Message 9 of 11  
02 Jul 12 13:24
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 23 Feb 2000
Posts To This List: 3966
Re: Reparsing from a (successful) post-open?
No. Forward all calls, FastIos included, to the second fake file. Or just plain disable FastIo in this case. I believe this second fake file is a dummy, something like the .EXE with a single MessageBox("You have tried to run the unsecure program") call. -- Maxim S. Shatskih Windows DDK MVP xxxxx@storagecraft.com http://www.storagecraft.com "Dejan Maksimovic" <xxxxx@alfasp.com> wrote in message news:94172@ntfsd... > > Nope :( We need to provide different data (from the reparsed version file). If we let the original open succeed, the data cache will be corrupted. > > Regards, Dejan. > > "Maxim S. Shatskih" wrote: > >> > mentioned, there are cases where I might need to check every file on the system >> >> Try this: <...excess quoted lines suppressed...>
  Message 10 of 11  
02 Jul 12 15:15
Dejan Maksimovic
xxxxxx@alfasp.com
Join Date: 18 Jul 2001
Posts To This List: 1448
Re: Reparsing from a (successful) post-open?
I cannot. Because the first file will be accessed as well. And when the first file is accessed, considering the file object that the app uses represents IT, then my redirection will not work for memory mapped regions. "Maxim S. Shatskih" wrote: > No. > > Forward all calls, FastIos included, to the second fake file. Or just plain disable FastIo in this case. > > I believe this second fake file is a dummy, something like the .EXE with a single MessageBox("You have tried to run the unsecure program") call. > > -- > Maxim S. Shatskih > Windows DDK MVP > xxxxx@storagecraft.com <...excess quoted lines suppressed...> -- Kind regards, Dejan (MSN support: xxxxx@alfasp.com) http://www.alfasp.com File system audit, security and encryption kits.
  Message 11 of 11  
03 Jul 12 05:40
yearstech
xxxxxx@sohu.com
Join Date: 22 May 2007
Posts To This List: 1
RE: Reparsing from a (successful) post-open?
I think you should reference SimRep sample. If create a new file,it has nothing to do with reparse.I am not sure if I am wrong.
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntfsd list to be able to post.

All times are GMT -5. The time now is 04:08.

Contact Us - Osr Online Homepage - Top

Copyright ©2012, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license