We have implemented a network redirector which supports UNC names.
To work in conunction with the MUP , our network redirector does the
following things.
- Registers itself with the MUP , using system supplied support routine
called FsrtlRegisterUncProvider().This is done in our driver
initialzation
routine i.e DriverEntry(). - We respond to special IOCTL i.e (IOCTL_REDIR_QUERY_PATH)
issued by MUP , asking our driver to check whether it recognizes a
name.
We support the following UNC names “.:”(dot-colon) , “:”(colon).
The network redirector i.e (File System Driver) is implemented for NT 4.0
and Windows 2000 platforms.
Executing "dir \:" from the command prompt on NT 4.0 with our redirector
installed results in
C:\>dir \:\
Directory of \:\
07/31/2001 10:43a
.05/12/1989 11:00a ..
05/16/1997 01:31p tom
11/05/2001 10:31a apps
05/16/1997 02:36p common
03/01/2000 01:33p julia
10/12/2000 01:48p jack
07/09/2001 09:35a abc
09/25/1998 10:42a efg
01/26/1998 02:07p 43 hij
05/07/1998 11:04a john
11/14/2001 03:36p apple
1 File(s) 3,363 bytes
11 Dir(s) 0 bytes free
But if the same command is executed on Win 2000 with
our redirector installed the we get the following error.
C:\>dir \\:\
Directory of \\:
File Not Found
We have written a simple test application and found that CreateFile()
succeeds on file "\\:\" both on NT 4.0 and Win 2000.
hFile = CreateFile("\\\\:\\", GENERIC_READ, FILE_SHARE_READ, NULL,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL |FILE_FLAG_BACKUP_SEMANTICS , NULL);
In another test application that we call Win32 API FindFirstFile on
"\\:\*" .
WIN32_FIND_DATA FindFileData;
HANDLE hFind;
hFind = FindFirstFile("\\\\:\\*", &FindFileData);
if (hFind == INVALID_HANDLE_VALUE) {
printf ("FindFirstFile failed. GetLastError reports %d\n", GetLastError
());
} else {
printf ("First file: %s\n", FindFileData.cFileName);
FindClose(hFind);
}
When we execute this program on NT 4.0 the ourput is "First file: ." i.e
FindFileData.cFileName contains "."But the same program when executed
on Win 2000 failswith the call to FindFirstFile returning
INVALID_HANDLE_VALUE. GetLastError() returns FILE_NOT_FOUND.
From our driver traces we have the following observation regarding the
request
coming to our driver/redirector when we do dir "\\:\" from the command
prompt.
Case 1 : Win NT 4.0 - our driver/redirector traces
1. IOCTL reuqest IOCTL_REDIR_QUERY_PATH with path "\:\".This request is
gets
successfully completed by our driver and we accept the the path as
valid.
2. Create request(IRP_MJ_CREATE) on file "\:\".This request get
successfully executed
and the file is created/opened.
3. Directory listing request(IRP_MJ_DIRECTORY_CONTROL) which also gets
successfully
executed.
4. Close request(IRP_MJ_CLEANUP followed by IRP_MJ_CLOSE) on file "\:\".
This gets successfully executed and the file is closed
Case 2 : Win NT 2000 - our driver/redirector traces
1. IOCTL reuqest IOCTL_REDIR_QUERY_PATH with path "\:".This request is
gets
successfully completed by our driver and we accept the the path as
valid.
2. Create request(IRP_MJ_CREATE) on file "\:\".This request get
successfully executed
and the file is created/opened.
4. Close request(IRP_MJ_CLEANUP followed by IRP_MJ_CLOSE) on file "\:\".
This gets successfully executed and the file is closed
The important thing to note here is that in case of Win 2000 we don't
directory listing IRP
IRP_MJ_DIRECTORY_CONTROL request unlike on NT 4.0 where our driver gets
the
directory listing IRP and FinFirstFile Win 32 suceeds.
Apart from this difference the our FSD traces are identical for Win 2000
and NT 4.0.
I would like to know why does the Win 2000 I/O manager decide against
sending
IRP_MJ_DIRECTORY_CONTROL to our driver in execution of Win 32API
FindFirstFile as is being properly done on NT 4.0.?
Is is that they way UNC names are handled in Win 2000 is different than
the way they are handled in NT 4.0?Do we need to do anything additional
in our Win 2000 FSD to support UNC names?
Tarun,
xxxxx@yahoo.com
---
You are currently subscribed to ntfsd as: $subst('Recip.EmailAddr')
To unsubscribe send a blank email to leave-ntfsd-$subst('Recip.MemberIDChar')@lists.osr.com