Hi I am working on the Minifilter driver for HSM. I am intercepting the Create operation to know the file operation and sending a message to the service to recall the RP file. The service opens the file with the following signature.
hFile = CreateFileW( a_filePath_p,STANDARD_RIGHTS_READ | FILE_READ_ATTRIBUTES,
0, NULL,OPEN_EXISTING, FILE_FLAG_OPEN_REPARSE_POINT | FILE_FLAG_OPEN_NO_RECALL | FILE_FLAG_BACKUP_SEMANTICS,NULL);
I have an issue related to open of the file when the folder is shared on the network and rename the file.
I create a RP file and the filter driver starts listening to the Create operation. I share the folder where I have created the RP file and map it on another machine. When I try to rename the file from another machine, I am receiving Create operation. Once I receive the Create I send a message to service before completing the IRP. When the service receives message, it try to create the file with FILE_READ_ATTRIBUTES.
This works fine when the another machine is not having the anti virus. But when the anti virus is started, I receive Create operation from another machine. Before I complete it, I send a message to service. When the service calls the CreateFile with the above parameters, the IO manager is not forwarding the call which results in the hang state.
Even I intercepted IRP_MJ_LOCK_CONTROL but nowhere I am getting lock/unlock operation calls. Also the desired access is same in both tests and even the Filemon not showing the logs for LOCK/UNLOCK. Following is the log from FileMon.
1 explorer.exe:1716 DIRECTORY SUCCESS FileBothDirectoryInformation: Hello.txt
2 explorer.exe:1716 OPEN Hello.txt SUCCESS Options: Open Access: Read-Attributes
3 explorer.exe:1716 QUERY INFORMATION Hello.txt SUCCESS FileBasicInformation
4 explorer.exe:1716 CLOSE Hello.txt SUCCESS
5 explorer.exe:1716 DIRECTORY SUCCESS FileBothDirectoryInformation: Hello.txt
6 explorer.exe:1716 OPEN Hello.txt SUCCESS Options: Open Access: 00110080
7 explorer.exe:1716 QUERY INFORMATION Hello.txt SUCCESS FileAttributeTagInformation
8 explorer.exe:1716 QUERY INFORMATION Hello.txt SUCCESS FileBasicInformation
9 explorer.exe:1716 OPEN Hello1.txt SUCCESS Options: Open Access: 00100002
10explorer.exe:1716 QUERY INFORMATION Hello1.txt INVALID PARAMETER FileBasicInformation
11explorer.exe:1716 SET INFORMATION Hello.txt SUCCESS FileRenameInformation
12explorer.exe:1716 CLOSE Hello.txt SUCCESS
13explorer.exe:1716 DIRECTORY SUCCESS FileBothDirectoryInformation: Hello1.txt
14explorer.exe:1716 DIRECTORY SUCCESS FileBothDirectoryInformation: Hello1.txt
15explorer.exe:1716 DIRECTORY SUCCESS FileBothDirectoryInformation: Hello1.txt
I need to know how whether the antivirus is locking the file. if yes how it can lock apart from calling standard IRP_MJ_LOCK_CONTROL? Or will it use some other techniques to lock the file?
You filter is installer on a machine which is providing a share (lets
call this the Server)
AV is filtering on the machine which has mapped the share (the client).
The hang happens on the Server because your service doesn’t get back from
a create it sends down?
The trace you send is from the client? (otherwise, where does
explorer.exe come in to play?)
If so…
You are going to have to dive in and look at this from the debugger. This
actually doesn’t feel like a byte range lock issue - that wouldn’t get in
the way of the the create. It could well be oplocks, but if it was you’d
see the pre-create call
If I am right, in my summary there are (at least) two prongs to attack this
Fire up the debugger and take a poke around the hung system. What is the
thread that issued the create waiting on (“!process 0 7 MyService.exe”)?
Are there any locks outstanding (“!locks”)?
Try and get SRV/RDR out of the equation. There is no “secret backdoor”
between SRV and the filesystem, and so anything which can be done from the
client can be done on the server by an appropriate test program. Just run
FileMon on the server and see what SRV is doing, then try to reproduce it on
the server with no client (FileTest is your friend).
Good luck.
By the way, pardon my ignorance but what is an RP file?
wrote in message news:xxxxx@ntfsd… > Hi I am working on the Minifilter driver for HSM. I am intercepting the > Create operation to know the file operation and sending a message to the > service to recall the RP file. The service opens the file with the > following signature. > hFile = CreateFileW( a_filePath_p,STANDARD_RIGHTS_READ | > FILE_READ_ATTRIBUTES, > 0, NULL,OPEN_EXISTING, > FILE_FLAG_OPEN_REPARSE_POINT | FILE_FLAG_OPEN_NO_RECALL | > FILE_FLAG_BACKUP_SEMANTICS,NULL); > > I have an issue related to open of the file when the folder is shared on > the network and rename the file. > > I create a RP file and the filter driver starts listening to the Create > operation. I share the folder where I have created the RP file and map it > on another machine. When I try to rename the file from another machine, I > am receiving Create operation. Once I receive the Create I send a message > to service before completing the IRP. When the service receives message, > it try to create the file with FILE_READ_ATTRIBUTES. > This works fine when the another machine is not having the anti virus. But > when the anti virus is started, I receive Create operation from another > machine. Before I complete it, I send a message to service. When the > service calls the CreateFile with the above parameters, the IO manager is > not forwarding the call which results in the hang state. > > Even I intercepted IRP_MJ_LOCK_CONTROL but nowhere I am getting > lock/unlock operation calls. Also the desired access is same in both tests > and even the Filemon not showing the logs for LOCK/UNLOCK. Following is > the log from FileMon. > > 1 explorer.exe:1716 DIRECTORY SUCCESS > FileBothDirectoryInformation: Hello.txt > 2 explorer.exe:1716 OPEN Hello.txt SUCCESS Options: Open Access: > Read-Attributes > 3 explorer.exe:1716 QUERY INFORMATION Hello.txt SUCCESS > FileBasicInformation > 4 explorer.exe:1716 CLOSE Hello.txt SUCCESS > 5 explorer.exe:1716 DIRECTORY SUCCESS > FileBothDirectoryInformation: Hello.txt > 6 explorer.exe:1716 OPEN Hello.txt SUCCESS Options: Open Access: > 00110080 > 7 explorer.exe:1716 QUERY INFORMATION Hello.txt SUCCESS > FileAttributeTagInformation > 8 explorer.exe:1716 QUERY INFORMATION Hello.txt SUCCESS > FileBasicInformation > 9 explorer.exe:1716 OPEN Hello1.txt SUCCESS Options: Open Access: > 00100002 > 10explorer.exe:1716 QUERY INFORMATION Hello1.txt INVALID PARAMETER > FileBasicInformation > 11explorer.exe:1716 SET INFORMATION Hello.txt SUCCESS > FileRenameInformation > 12explorer.exe:1716 CLOSE Hello.txt SUCCESS > 13explorer.exe:1716 DIRECTORY SUCCESS > FileBothDirectoryInformation: Hello1.txt > 14explorer.exe:1716 DIRECTORY SUCCESS > FileBothDirectoryInformation: Hello1.txt > 15explorer.exe:1716 DIRECTORY SUCCESS > FileBothDirectoryInformation: Hello1.txt > > > I need to know how whether the antivirus is locking the file. if yes how > it can lock apart from calling standard IRP_MJ_LOCK_CONTROL? Or will it > use some other techniques to lock the file? >
Hi Thanks for the reply. The RP refered reparse point. The terminology used as server and client is correct.
I work on your inputs. I verified that there is no lock happening on the reparse file both in server and client. I tried inspecting the IRP_MJ_LOCK_CONTROL and IRP_MJ_SYSTEM_CONTROL. Where there is no LockFile API call nor it looks like no FSCtl function calls.
Also the desired access for normal network access and client access which has antivirus is similar. There is no difference in that.
Even interestingly I used one more antivirus. Where the client installed with this AV will not be able to recall the reparse file even for create operation.
The oplocks will call the IRP_MJ_SYSTEM_CONTROL am I right?
is there any other ways where antivirus can lock the file apart from LockFile and FSCtl functions?
Do this problem is really because of the antivrus locking the file?
You are going to have to fire up the debugger to get more information. You
will probably find that at that stage you will start getting network
timeouts and will want to get this reproduced on a single machine…
wrote in message news:xxxxx@ntfsd… > Hi Thanks for the reply. The RP refered reparse point. The terminology > used as server and client is correct. > > I work on your inputs. I verified that there is no lock happening on the > reparse file both in server and client. I tried inspecting the > IRP_MJ_LOCK_CONTROL and IRP_MJ_SYSTEM_CONTROL. Where there is no LockFile > API call nor it looks like no FSCtl function calls. > Also the desired access for normal network access and client access which > has antivirus is similar. There is no difference in that. > > Even interestingly I used one more antivirus. Where the client installed > with this AV will not be able to recall the reparse file even for create > operation. > > The oplocks will call the IRP_MJ_SYSTEM_CONTROL am I right? > is there any other ways where antivirus can lock the file apart from > LockFile and FSCtl functions? > Do this problem is really because of the antivrus locking the file? >
You really should not be recalling the file at create time. It will cause lots of problems with an HSM implementation. A simple rename of the file that does not involve moving it to another drive does not need to recall the data anyway. The preferred way to handle it is to add context to the file object at create time and wait for the first read or write to recall the file. If you recall it on every create you will recall it at times when the data is not going to be read and waste a lot of resources doing unnecessary work. There are also deadlocks that can occur with the redirector/server and problems like you are seeing with anti-virus as well.