hi,
i used the FILE_CREATE_TREE_CONNECTION flag to detect an open to a network
share. however, i have encountered cases where a network share can be opened
w/o specifying the flag. in these cases, the share seen in Windows Explorer
is something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. how can i detect an open
in these cases?
thanks.
Ampsi
It sounds like DFS is in the picture. An open to a UNC name will go through
DFS translation can hit the SMB redirector already translated.
In any case, you don’t necessarily needs a FILE_CREATE_TREE_CONNECTION to
connect to a share.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Wednesday, May 12, 2004 7:59 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FILE_CREATE_TREE_CONNECTION
hi,
i used the FILE_CREATE_TREE_CONNECTION flag to detect an open to a network
share. however, i have encountered cases where a network share can be opened
w/o specifying the flag. in these cases, the share seen in Windows Explorer
is something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. how can i detect an open
in these cases?
thanks.
Ampsi
so is there another way to detect opening of shares other than relying on
FILE_CREATE_TREE_CONNECTION?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 13, 2004 14:26
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
It sounds like DFS is in the picture. An open to a UNC name will go through
DFS translation can hit the SMB redirector already translated.
In any case, you don’t necessarily needs a FILE_CREATE_TREE_CONNECTION to
connect to a share.
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Wednesday, May 12, 2004 7:59 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FILE_CREATE_TREE_CONNECTION
hi,
i used the FILE_CREATE_TREE_CONNECTION flag to detect an open to a network
share. however, i have encountered cases where a network share can be opened
w/o specifying the flag. in these cases, the share seen in Windows Explorer
is something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. how can i detect an open
in these cases?
thanks.
Ampsi
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
What do you mean by the opening of shares? People can connect to a UNC path
directly. Would you want to catch that?
It is not altogether clear what you are trying to accomplish. What is it
the high-level goal that you are trying to achieve?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 12:04 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
so is there another way to detect opening of shares other than relying on
FILE_CREATE_TREE_CONNECTION?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 13, 2004 14:26
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
It sounds like DFS is in the picture. An open to a UNC name will go through
DFS translation can hit the SMB redirector already translated.
In any case, you don’t necessarily needs a FILE_CREATE_TREE_CONNECTION to
connect to a share.
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Wednesday, May 12, 2004 7:59 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FILE_CREATE_TREE_CONNECTION
hi,
i used the FILE_CREATE_TREE_CONNECTION flag to detect an open to a network
share. however, i have encountered cases where a network share can be opened
w/o specifying the flag. in these cases, the share seen in Windows Explorer
is something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. how can i detect an open
in these cases?
thanks.
Ampsi
i am trying to associate a drive letter to a share for filename checking.
when FILE_CREATE_TREE_CONNECTION is used in create for opening of a share,
the filename will consist of the drive letter as well as the server share
path.
however, i just found out that in the case i described below where
FILE_CREATE_TREE_CONNECTION is not used, there is no drive letter in any of
the filenames of any create related to the opening of the share. so even if
i can detect the opening of a share w/o FILE_CREATE_TREE_CONNECTION, i still
cannot get my drive letter.
is there any method to resolve a drive letter to a server share?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 00:21
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
What do you mean by the opening of shares? People can connect to a UNC path
directly. Would you want to catch that?
It is not altogether clear what you are trying to accomplish. What is it
the high-level goal that you are trying to achieve?
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 12:04 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
so is there another way to detect opening of shares other than relying on
FILE_CREATE_TREE_CONNECTION?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 13, 2004 14:26
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
It sounds like DFS is in the picture. An open to a UNC name will go through
DFS translation can hit the SMB redirector already translated.
In any case, you don’t necessarily needs a FILE_CREATE_TREE_CONNECTION to
connect to a share.
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Wednesday, May 12, 2004 7:59 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FILE_CREATE_TREE_CONNECTION
hi,
i used the FILE_CREATE_TREE_CONNECTION flag to detect an open to a network
share. however, i have encountered cases where a network share can be opened
w/o specifying the flag. in these cases, the share seen in Windows Explorer
is something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. how can i detect an open
in these cases?
thanks.
Ampsi
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The way remote file systems map drive letters is by creating an NT
symbolic link from the drive letter to the redirector name thus:
\Device\LanmanRedirector;X:\server\share
(for drive letter connections to SMB shares for instance. Note, this is
just an example, it’s different if DFS is in picture, and don’t rely on
this, this kind of stuff can change between OS versions).
You should be able to look up the drive letter —> symbolic link target
via ZwOpenSymbolicObject & ZwQuerySymbolicObject.
By the time Ob parses & strips it off, what the redirector itself would
see is:
;X\server\share.
If relative opens are done against such an open of course, you wouldn’t
see any of this stuff in the relative file name.
Tree connections are different from opening the root directory of a
share. You probably don’t want to use them unless you understand what
they are for.
If the drive letter was associated with a DFS path, and you are
filtering above the RDR, you will not see the drive letter and stuff
because DFS translates - as DaniLo points out - to an underlying UNC
path. DFS itself does tree connections to UNC paths if explicit
credentials were supplied for a connection.
This is essentially a brain dump from my side since I really don’t know
what you want, hopefully you will find some answers above. If not you
probably want to really tell us
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 6:16 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
i am trying to associate a drive letter to a share for filename
checking.
when FILE_CREATE_TREE_CONNECTION is used in create for opening of a
share, the filename will consist of the drive letter as well as the
server share path.
however, i just found out that in the case i described below where
FILE_CREATE_TREE_CONNECTION is not used, there is no drive letter in any
of the filenames of any create related to the opening of the share. so
even if i can detect the opening of a share w/o
FILE_CREATE_TREE_CONNECTION, i still cannot get my drive letter.
is there any method to resolve a drive letter to a server share?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 00:21
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
What do you mean by the opening of shares? People can connect to a UNC
path
directly. Would you want to catch that?
It is not altogether clear what you are trying to accomplish. What is
it
the high-level goal that you are trying to achieve?
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 12:04 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
so is there another way to detect opening of shares other than relying
on
FILE_CREATE_TREE_CONNECTION?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 13, 2004 14:26
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
It sounds like DFS is in the picture. An open to a UNC name will go
through
DFS translation can hit the SMB redirector already translated.
In any case, you don’t necessarily needs a FILE_CREATE_TREE_CONNECTION
to
connect to a share.
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Wednesday, May 12, 2004 7:59 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FILE_CREATE_TREE_CONNECTION
hi,
i used the FILE_CREATE_TREE_CONNECTION flag to detect an open to a
network
share. however, i have encountered cases where a network share can be
opened
w/o specifying the flag. in these cases, the share seen in Windows
Explorer
is something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. how can i detect an
open
in these cases?
thanks.
Ampsi
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
like i wrote earlier, what i want is to associate a drive letter to a share
for filename checking. say if h: is mapped to \server\share, i would want
to know h:\a.txt is actually \server\share\a.txt, and vice versa.
this is because i need to use filename in the form of h:\a.txt for checking
against some rules specified in the said format. so if the file is opened in
the \server\share\a.txt format, i will need to translate it to h:\a.txt. at
the same time, i will also need the filename to be in the
\server\share\a.txt format in order to open it at the driver level. so in
rename operations where the filename can be in the \??\h:\a.txt, i will
need to know that h: is \server\share.
come to think of it, i can use \??\h:\a.txt to open the file in kernel,
right?
Ampsi
----- Original Message -----
From: “Ravisankar Pudipeddi”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 10:12
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
The way remote file systems map drive letters is by creating an NT
symbolic link from the drive letter to the redirector name thus:
\Device\LanmanRedirector;X:\server\share
(for drive letter connections to SMB shares for instance. Note, this is
just an example, it’s different if DFS is in picture, and don’t rely on
this, this kind of stuff can change between OS versions).
You should be able to look up the drive letter —> symbolic link target
via ZwOpenSymbolicObject & ZwQuerySymbolicObject.
By the time Ob parses & strips it off, what the redirector itself would
see is:
;X\server\share.
If relative opens are done against such an open of course, you wouldn’t
see any of this stuff in the relative file name.
Tree connections are different from opening the root directory of a
share. You probably don’t want to use them unless you understand what
they are for.
If the drive letter was associated with a DFS path, and you are
filtering above the RDR, you will not see the drive letter and stuff
because DFS translates - as DaniLo points out - to an underlying UNC
path. DFS itself does tree connections to UNC paths if explicit
credentials were supplied for a connection.
This is essentially a brain dump from my side since I really don’t know
what you want, hopefully you will find some answers above. If not you
probably want to really tell us
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 6:16 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
i am trying to associate a drive letter to a share for filename
checking.
when FILE_CREATE_TREE_CONNECTION is used in create for opening of a
share, the filename will consist of the drive letter as well as the
server share path.
however, i just found out that in the case i described below where
FILE_CREATE_TREE_CONNECTION is not used, there is no drive letter in any
of the filenames of any create related to the opening of the share. so
even if i can detect the opening of a share w/o
FILE_CREATE_TREE_CONNECTION, i still cannot get my drive letter.
is there any method to resolve a drive letter to a server share?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 00:21
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
What do you mean by the opening of shares? People can connect to a UNC
path
directly. Would you want to catch that?
It is not altogether clear what you are trying to accomplish. What is
it
the high-level goal that you are trying to achieve?
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 12:04 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
so is there another way to detect opening of shares other than relying
on
FILE_CREATE_TREE_CONNECTION?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 13, 2004 14:26
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
It sounds like DFS is in the picture. An open to a UNC name will go
through
DFS translation can hit the SMB redirector already translated.
In any case, you don’t necessarily needs a FILE_CREATE_TREE_CONNECTION
to
connect to a share.
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Wednesday, May 12, 2004 7:59 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FILE_CREATE_TREE_CONNECTION
hi,
i used the FILE_CREATE_TREE_CONNECTION flag to detect an open to a
network
share. however, i have encountered cases where a network share can be
opened
w/o specifying the flag. in these cases, the share seen in Windows
Explorer
is something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. how can i detect an
open
in these cases?
thanks.
Ampsi
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi Ampsi,
There is a ptoential flaw in the mechanism you are using, because it
presumes that there is some unique structure to the name of the file.
However, consider the following scenario:
A server exports two shares by doing the following:
“net share foo=c:\foo”
“net share bar=c:\foo\bar”
A client then maps these:
“net use * \server\foo”
“net use * \server\bar”
Suppose that the first is assigned drive letter Z: and the second Y:
I then open the files:
Z:\bar\file.txt
Y:\file.txt
How will you associate these two files together? In addition, suppose a
client only maps the second one and then a user on that client machine
uses Explorer to browse the “Network Neighborhood” (which translates to
a UNC open) and browses via the first share. The UNC name now becomes
“\server\foo\bar\file.txt” and the drive letter name is “y:\file.txt”.
I mention this last case, because a simple technique for dealing with
this is to look at the drive letter in the object manager name space
(there are ZwXxx APIs for opening and reading object manager symbolic
link names). That drive letter will contain name information (the
format varies by version, but in XP, for example, it will map to
something like “;Y:00000000000144b4\server\bar” (of course, to find this
mapping you will need to look in “\Session<session>#>\DosDevices<session id><drive letter>”. The problem with this
technique is that it doesn’t work.
Indeed, the only reliable way of which I know to associate two remote
files with one another is to use a server-side assist. We’ve done that
here at OSR in the past - with a server side filter driver, you can
tunnel across the network, ask the remote side for the file ID, and then
associate the two files with one another using the file ID.
With respect to rules based engines, you are FAR better off forcing
people to specify UNC names and then converting the drive letter path
into a UNC style name. But even then, you’ll need to do some serious
work to find the overlapping names and even then I can construct trivial
scenarios that will cause hideous problems for you (think “multiple
drive letters” and “mount points” on the server side and you will see
some of the problems inherent here.)
And that is why I always suggest to people that they use a server-side
assist. I CAN overcome all of these issues using a server side assist.
Barring that, you end up documenting restrictions on how people can
export the drives on their remote machines.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Friday, May 14, 2004 1:56 AM
To: ntfsd redirect
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
like i wrote earlier, what i want is to associate a drive letter to a
share for filename checking. say if h: is mapped to \server\share, i
would want to know h:\a.txt is actually \server\share\a.txt, and vice
versa.
this is because i need to use filename in the form of h:\a.txt for
checking against some rules specified in the said format. so if the file
is opened in the \server\share\a.txt format, i will need to translate
it to h:\a.txt. at the same time, i will also need the filename to be in
the \server\share\a.txt format in order to open it at the driver level.
so in rename operations where the filename can be in the \??\h:\a.txt,
i will need to know that h: is \server\share.
come to think of it, i can use \??\h:\a.txt to open the file in kernel,
right?
Ampsi
----- Original Message -----
From: “Ravisankar Pudipeddi”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 10:12
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
The way remote file systems map drive letters is by creating an NT
symbolic link from the drive letter to the redirector name thus:
\Device\LanmanRedirector;X:\server\share
(for drive letter connections to SMB shares for instance. Note, this is
just an example, it’s different if DFS is in picture, and don’t rely on
this, this kind of stuff can change between OS versions).
You should be able to look up the drive letter —> symbolic link target
via ZwOpenSymbolicObject & ZwQuerySymbolicObject.
By the time Ob parses & strips it off, what the redirector itself would
see is:
;X\server\share.
If relative opens are done against such an open of course, you wouldn’t
see any of this stuff in the relative file name.
Tree connections are different from opening the root directory of a
share. You probably don’t want to use them unless you understand what
they are for.
If the drive letter was associated with a DFS path, and you are
filtering above the RDR, you will not see the drive letter and stuff
because DFS translates - as DaniLo points out - to an underlying UNC
path. DFS itself does tree connections to UNC paths if explicit
credentials were supplied for a connection.
This is essentially a brain dump from my side since I really don’t know
what you want, hopefully you will find some answers above. If not you
probably want to really tell us
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 6:16 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
i am trying to associate a drive letter to a share for filename
checking.
when FILE_CREATE_TREE_CONNECTION is used in create for opening of a
share, the filename will consist of the drive letter as well as the
server share path.
however, i just found out that in the case i described below where
FILE_CREATE_TREE_CONNECTION is not used, there is no drive letter in any
of the filenames of any create related to the opening of the share. so
even if i can detect the opening of a share w/o
FILE_CREATE_TREE_CONNECTION, i still cannot get my drive letter.
is there any method to resolve a drive letter to a server share?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 00:21
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
What do you mean by the opening of shares? People can connect to a UNC
path
directly. Would you want to catch that?
It is not altogether clear what you are trying to accomplish. What is
it
the high-level goal that you are trying to achieve?
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 12:04 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
so is there another way to detect opening of shares other than relying
on
FILE_CREATE_TREE_CONNECTION?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 13, 2004 14:26
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
It sounds like DFS is in the picture. An open to a UNC name will go
through
DFS translation can hit the SMB redirector already translated.
In any case, you don’t necessarily needs a FILE_CREATE_TREE_CONNECTION
to
connect to a share.
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Wednesday, May 12, 2004 7:59 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FILE_CREATE_TREE_CONNECTION
hi,
i used the FILE_CREATE_TREE_CONNECTION flag to detect an open to a
network
share. however, i have encountered cases where a network share can be
opened
w/o specifying the flag. in these cases, the share seen in Windows
Explorer
is something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. how can i detect an
open
in these cases?
thanks.
Ampsi
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Tony,
What actually is important for for my filter to know is the drive letter, as
my filter checks some rules using the drive letter. to my knowledge, there
are only 2 broad ways to specify a filename for files on remote shares. one
is the “\x:\server\share\filename.extension” format while the other is the
“\server\share\filename.extension” format. in the first format, i already
can get the drive letter from the filename. to handle the second format, i
trap the FILE_CREATE_TREE_CONNECTION call as the filename in the call is in
the “\x:\server\share” format. with this info, i can create a mapping table
from drive letter to “\server\share”.
if Y: is \server\bar and Z: is \server\foo, when \server\bar\file.txt is
opened, my filter will know file.txt comes from Y:, and when
\server\foo\bar\file.txt is opened, my filter will know file.txt comes from
Z:.
in addition, my filter prevents mulitple drive mappings to the same
\server\share to avoid drive letter confusion. of course, this can only be
done now as my filter traps the FILE_CREATE_TREE_CONNECTION flag. i have
also specified to the system admins not to create shares that are within
each other, such as in your example, as this will confuse the filter as
well.
so now with DFS, no create with FILE_CREATE_TREE_CONNECTION is called, and
thus my drive mapping table is empty. so what i hope to find is a way for my
filter to be able to fill up this mappin table.
Ampsi
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 17:23
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
Hi Ampsi,
There is a ptoential flaw in the mechanism you are using, because it
presumes that there is some unique structure to the name of the file.
However, consider the following scenario:
A server exports two shares by doing the following:
“net share foo=c:\foo”
“net share bar=c:\foo\bar”
A client then maps these:
“net use * \server\foo”
“net use * \server\bar”
Suppose that the first is assigned drive letter Z: and the second Y:
I then open the files:
Z:\bar\file.txt
Y:\file.txt
How will you associate these two files together? In addition, suppose a
client only maps the second one and then a user on that client machine
uses Explorer to browse the “Network Neighborhood” (which translates to
a UNC open) and browses via the first share. The UNC name now becomes
“\server\foo\bar\file.txt” and the drive letter name is “y:\file.txt”.
I mention this last case, because a simple technique for dealing with
this is to look at the drive letter in the object manager name space
(there are ZwXxx APIs for opening and reading object manager symbolic
link names). That drive letter will contain name information (the
format varies by version, but in XP, for example, it will map to
something like “;Y:00000000000144b4\server\bar” (of course, to find this
mapping you will need to look in “\Session<session>#>\DosDevices<session id><drive letter>”. The problem with this
technique is that it doesn’t work.
Indeed, the only reliable way of which I know to associate two remote
files with one another is to use a server-side assist. We’ve done that
here at OSR in the past - with a server side filter driver, you can
tunnel across the network, ask the remote side for the file ID, and then
associate the two files with one another using the file ID.
With respect to rules based engines, you are FAR better off forcing
people to specify UNC names and then converting the drive letter path
into a UNC style name. But even then, you’ll need to do some serious
work to find the overlapping names and even then I can construct trivial
scenarios that will cause hideous problems for you (think “multiple
drive letters” and “mount points” on the server side and you will see
some of the problems inherent here.)
And that is why I always suggest to people that they use a server-side
assist. I CAN overcome all of these issues using a server side assist.
Barring that, you end up documenting restrictions on how people can
export the drives on their remote machines.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Friday, May 14, 2004 1:56 AM
To: ntfsd redirect
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
like i wrote earlier, what i want is to associate a drive letter to a
share for filename checking. say if h: is mapped to \server\share, i
would want to know h:\a.txt is actually \server\share\a.txt, and vice
versa.
this is because i need to use filename in the form of h:\a.txt for
checking against some rules specified in the said format. so if the file
is opened in the \server\share\a.txt format, i will need to translate
it to h:\a.txt. at the same time, i will also need the filename to be in
the \server\share\a.txt format in order to open it at the driver level.
so in rename operations where the filename can be in the \??\h:\a.txt,
i will need to know that h: is \server\share.
come to think of it, i can use \??\h:\a.txt to open the file in kernel,
right?
Ampsi
----- Original Message -----
From: “Ravisankar Pudipeddi”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 10:12
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
The way remote file systems map drive letters is by creating an NT
symbolic link from the drive letter to the redirector name thus:
\Device\LanmanRedirector;X:\server\share
(for drive letter connections to SMB shares for instance. Note, this is
just an example, it’s different if DFS is in picture, and don’t rely on
this, this kind of stuff can change between OS versions).
You should be able to look up the drive letter —> symbolic link target
via ZwOpenSymbolicObject & ZwQuerySymbolicObject.
By the time Ob parses & strips it off, what the redirector itself would
see is:
;X\server\share.
If relative opens are done against such an open of course, you wouldn’t
see any of this stuff in the relative file name.
Tree connections are different from opening the root directory of a
share. You probably don’t want to use them unless you understand what
they are for.
If the drive letter was associated with a DFS path, and you are
filtering above the RDR, you will not see the drive letter and stuff
because DFS translates - as DaniLo points out - to an underlying UNC
path. DFS itself does tree connections to UNC paths if explicit
credentials were supplied for a connection.
This is essentially a brain dump from my side since I really don’t know
what you want, hopefully you will find some answers above. If not you
probably want to really tell us
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 6:16 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
i am trying to associate a drive letter to a share for filename
checking.
when FILE_CREATE_TREE_CONNECTION is used in create for opening of a
share, the filename will consist of the drive letter as well as the
server share path.
however, i just found out that in the case i described below where
FILE_CREATE_TREE_CONNECTION is not used, there is no drive letter in any
of the filenames of any create related to the opening of the share. so
even if i can detect the opening of a share w/o
FILE_CREATE_TREE_CONNECTION, i still cannot get my drive letter.
is there any method to resolve a drive letter to a server share?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 00:21
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
What do you mean by the opening of shares? People can connect to a UNC
path
directly. Would you want to catch that?
It is not altogether clear what you are trying to accomplish. What is
it
the high-level goal that you are trying to achieve?
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 12:04 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
so is there another way to detect opening of shares other than relying
on
FILE_CREATE_TREE_CONNECTION?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 13, 2004 14:26
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
It sounds like DFS is in the picture. An open to a UNC name will go
through
DFS translation can hit the SMB redirector already translated.
In any case, you don’t necessarily needs a FILE_CREATE_TREE_CONNECTION
to
connect to a share.
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Wednesday, May 12, 2004 7:59 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FILE_CREATE_TREE_CONNECTION
hi,
i used the FILE_CREATE_TREE_CONNECTION flag to detect an open to a
network
share. however, i have encountered cases where a network share can be
opened
w/o specifying the flag. in these cases, the share seen in Windows
Explorer
is something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. how can i detect an
open
in these cases?
thanks.
Ampsi
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I have no idea how you are trapping the UNC names from your example.
You keep focusing on drive letters, but the point here is that drive
letters are not required to access a remote resource.
For example, try writing a program of your own that opens a remote
resource (“\server\share\foo\bar.txt”) and see what you observe in your
filter. I do not expect that you will see a FILE_CREATE_TREE_CONNECTION
call in that instance, either.
Good luck!
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Wednesday, May 19, 2004 10:42 PM
To: ntfsd redirect
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
Tony,
What actually is important for for my filter to know is the drive
letter, as my filter checks some rules using the drive letter. to my
knowledge, there are only 2 broad ways to specify a filename for files
on remote shares. one is the “\x:\server\share\filename.extension”
format while the other is the “\server\share\filename.extension” format.
in the first format, i already can get the drive letter from the
filename. to handle the second format, i trap the
FILE_CREATE_TREE_CONNECTION call as the filename in the call is in the
“\x:\server\share” format. with this info, i can create a mapping table
from drive letter to “\server\share”.
if Y: is \server\bar and Z: is \server\foo, when \server\bar\file.txt
is opened, my filter will know file.txt comes from Y:, and when
\server\foo\bar\file.txt is opened, my filter will know file.txt comes
from Z:.
in addition, my filter prevents mulitple drive mappings to the same
\server\share to avoid drive letter confusion. of course, this can only
be done now as my filter traps the FILE_CREATE_TREE_CONNECTION flag. i
have also specified to the system admins not to create shares that are
within each other, such as in your example, as this will confuse the
filter as well.
so now with DFS, no create with FILE_CREATE_TREE_CONNECTION is called,
and thus my drive mapping table is empty. so what i hope to find is a
way for my filter to be able to fill up this mappin table.
Ampsi
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 17:23
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
Hi Ampsi,
There is a ptoential flaw in the mechanism you are using, because it
presumes that there is some unique structure to the name of the file.
However, consider the following scenario:
A server exports two shares by doing the following:
“net share foo=c:\foo”
“net share bar=c:\foo\bar”
A client then maps these:
“net use * \server\foo”
“net use * \server\bar”
Suppose that the first is assigned drive letter Z: and the second Y:
I then open the files:
Z:\bar\file.txt
Y:\file.txt
How will you associate these two files together? In addition, suppose a
client only maps the second one and then a user on that client machine
uses Explorer to browse the “Network Neighborhood” (which translates to
a UNC open) and browses via the first share. The UNC name now becomes
“\server\foo\bar\file.txt” and the drive letter name is “y:\file.txt”.
I mention this last case, because a simple technique for dealing with
this is to look at the drive letter in the object manager name space
(there are ZwXxx APIs for opening and reading object manager symbolic
link names). That drive letter will contain name information (the
format varies by version, but in XP, for example, it will map to
something like “;Y:00000000000144b4\server\bar” (of course, to find this
mapping you will need to look in “\Session<session>#>\DosDevices<session id><drive letter>”. The problem with this
technique is that it doesn’t work.
Indeed, the only reliable way of which I know to associate two remote
files with one another is to use a server-side assist. We’ve done that
here at OSR in the past - with a server side filter driver, you can
tunnel across the network, ask the remote side for the file ID, and then
associate the two files with one another using the file ID.
With respect to rules based engines, you are FAR better off forcing
people to specify UNC names and then converting the drive letter path
into a UNC style name. But even then, you’ll need to do some serious
work to find the overlapping names and even then I can construct trivial
scenarios that will cause hideous problems for you (think “multiple
drive letters” and “mount points” on the server side and you will see
some of the problems inherent here.)
And that is why I always suggest to people that they use a server-side
assist. I CAN overcome all of these issues using a server side assist.
Barring that, you end up documenting restrictions on how people can
export the drives on their remote machines.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Friday, May 14, 2004 1:56 AM
To: ntfsd redirect
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
like i wrote earlier, what i want is to associate a drive letter to a
share for filename checking. say if h: is mapped to \server\share, i
would want to know h:\a.txt is actually \server\share\a.txt, and vice
versa.
this is because i need to use filename in the form of h:\a.txt for
checking against some rules specified in the said format. so if the file
is opened in the \server\share\a.txt format, i will need to translate
it to h:\a.txt. at the same time, i will also need the filename to be in
the \server\share\a.txt format in order to open it at the driver level.
so in rename operations where the filename can be in the \??\h:\a.txt,
i will need to know that h: is \server\share.
come to think of it, i can use \??\h:\a.txt to open the file in kernel,
right?
Ampsi
----- Original Message -----
From: “Ravisankar Pudipeddi”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 10:12
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
The way remote file systems map drive letters is by creating an NT
symbolic link from the drive letter to the redirector name thus:
\Device\LanmanRedirector;X:\server\share
(for drive letter connections to SMB shares for instance. Note, this is
just an example, it’s different if DFS is in picture, and don’t rely on
this, this kind of stuff can change between OS versions).
You should be able to look up the drive letter —> symbolic link target
via ZwOpenSymbolicObject & ZwQuerySymbolicObject.
By the time Ob parses & strips it off, what the redirector itself would
see is:
;X\server\share.
If relative opens are done against such an open of course, you wouldn’t
see any of this stuff in the relative file name.
Tree connections are different from opening the root directory of a
share. You probably don’t want to use them unless you understand what
they are for.
If the drive letter was associated with a DFS path, and you are
filtering above the RDR, you will not see the drive letter and stuff
because DFS translates - as DaniLo points out - to an underlying UNC
path. DFS itself does tree connections to UNC paths if explicit
credentials were supplied for a connection.
This is essentially a brain dump from my side since I really don’t know
what you want, hopefully you will find some answers above. If not you
probably want to really tell us
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 6:16 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
i am trying to associate a drive letter to a share for filename
checking.
when FILE_CREATE_TREE_CONNECTION is used in create for opening of a
share, the filename will consist of the drive letter as well as the
server share path.
however, i just found out that in the case i described below where
FILE_CREATE_TREE_CONNECTION is not used, there is no drive letter in any
of the filenames of any create related to the opening of the share. so
even if i can detect the opening of a share w/o
FILE_CREATE_TREE_CONNECTION, i still cannot get my drive letter.
is there any method to resolve a drive letter to a server share?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 00:21
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
What do you mean by the opening of shares? People can connect to a UNC
path
directly. Would you want to catch that?
It is not altogether clear what you are trying to accomplish. What is
it
the high-level goal that you are trying to achieve?
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 12:04 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
so is there another way to detect opening of shares other than relying
on
FILE_CREATE_TREE_CONNECTION?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 13, 2004 14:26
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
It sounds like DFS is in the picture. An open to a UNC name will go
through
DFS translation can hit the SMB redirector already translated.
In any case, you don’t necessarily needs a FILE_CREATE_TREE_CONNECTION
to
connect to a share.
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Wednesday, May 12, 2004 7:59 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FILE_CREATE_TREE_CONNECTION
hi,
i used the FILE_CREATE_TREE_CONNECTION flag to detect an open to a
network
share. however, i have encountered cases where a network share can be
opened
w/o specifying the flag. in these cases, the share seen in Windows
Explorer
is something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. how can i detect an
open
in these cases?
thanks.
Ampsi
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> filter. I do not expect that you will see a FILE_CREATE_TREE_CONNECTION
call in that instance, either.
IIRC FILE_CREATE_TREE_CONNECTION is set only by the code in the NP DLL
(NTLANMAN.DLL), which implements the NET USE command and similar stuff.
The username/password information is passed as EAs.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
well, that’s precisely the problem. i need the drive letter for some checks
but network files can be opened w/o any drive letter. that is why i
implemented the drive mapping table based on trapping
FILE_CREATE_TREE_CONNECTION.
actually my scenario is quite simple. users access files on the servers
through drive mappings done through the login script. as the drive mappings
are already done for them during login, they will not be opening files
directly through the UNC name format. however, some applications may
sometimes use the UNC name format to access the files, and this is the
problem. before DFS, the drive mapping table can be updated when the login
script performed the mapping, as the mappings will be done with the
FILE_CREATE_TREE_CONNECTION flag. thus, my filter is able to resolve from
UNC to drive letter. with DFS, the mappings are not done with the
FILE_CREATE_TREE_CONNECTION flag, and the drive mapping table is empty.
thus, my filter is unable to perform a resolution. so now this is the
problem.
well, even if i don’t use drive letters for checking, there will still be a
problem with DFS if my filter is to do filename checking. as mentioned in my
very first mail, the mapping seen in Windows Explorer is something like
“company.com.sg\home\ampsi” but the path seen in the kernel is
“company-server2.com.sg\users\sp\ampsi”. so in this case, there is no match
if the rules is set using “company.com.sg\home\ampsi”. i don’t think it is
appropriate to set the rule with “company-server2.com.sg\users\sp\ampsi” as
the purpose of DFS is to encapsulate the actual servers with a common server
path.
so, is there a way to the drive letter, say by sending a request to DFS?
Ampsi
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 20, 2004 17:33
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
I have no idea how you are trapping the UNC names from your example.
You keep focusing on drive letters, but the point here is that drive
letters are not required to access a remote resource.
For example, try writing a program of your own that opens a remote
resource (“\server\share\foo\bar.txt”) and see what you observe in your
filter. I do not expect that you will see a FILE_CREATE_TREE_CONNECTION
call in that instance, either.
Good luck!
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Wednesday, May 19, 2004 10:42 PM
To: ntfsd redirect
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
Tony,
What actually is important for for my filter to know is the drive
letter, as my filter checks some rules using the drive letter. to my
knowledge, there are only 2 broad ways to specify a filename for files
on remote shares. one is the “\x:\server\share\filename.extension”
format while the other is the “\server\share\filename.extension” format.
in the first format, i already can get the drive letter from the
filename. to handle the second format, i trap the
FILE_CREATE_TREE_CONNECTION call as the filename in the call is in the
“\x:\server\share” format. with this info, i can create a mapping table
from drive letter to “\server\share”.
if Y: is \server\bar and Z: is \server\foo, when \server\bar\file.txt
is opened, my filter will know file.txt comes from Y:, and when
\server\foo\bar\file.txt is opened, my filter will know file.txt comes
from Z:.
in addition, my filter prevents mulitple drive mappings to the same
\server\share to avoid drive letter confusion. of course, this can only
be done now as my filter traps the FILE_CREATE_TREE_CONNECTION flag. i
have also specified to the system admins not to create shares that are
within each other, such as in your example, as this will confuse the
filter as well.
so now with DFS, no create with FILE_CREATE_TREE_CONNECTION is called,
and thus my drive mapping table is empty. so what i hope to find is a
way for my filter to be able to fill up this mappin table.
Ampsi
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 17:23
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
Hi Ampsi,
There is a ptoential flaw in the mechanism you are using, because it
presumes that there is some unique structure to the name of the file.
However, consider the following scenario:
A server exports two shares by doing the following:
“net share foo=c:\foo”
“net share bar=c:\foo\bar”
A client then maps these:
“net use * \server\foo”
“net use * \server\bar”
Suppose that the first is assigned drive letter Z: and the second Y:
I then open the files:
Z:\bar\file.txt
Y:\file.txt
How will you associate these two files together? In addition, suppose a
client only maps the second one and then a user on that client machine
uses Explorer to browse the “Network Neighborhood” (which translates to
a UNC open) and browses via the first share. The UNC name now becomes
“\server\foo\bar\file.txt” and the drive letter name is “y:\file.txt”.
I mention this last case, because a simple technique for dealing with
this is to look at the drive letter in the object manager name space
(there are ZwXxx APIs for opening and reading object manager symbolic
link names). That drive letter will contain name information (the
format varies by version, but in XP, for example, it will map to
something like “;Y:00000000000144b4\server\bar” (of course, to find this
mapping you will need to look in “\Session<session>#>\DosDevices<session id><drive letter>”. The problem with this
technique is that it doesn’t work.
Indeed, the only reliable way of which I know to associate two remote
files with one another is to use a server-side assist. We’ve done that
here at OSR in the past - with a server side filter driver, you can
tunnel across the network, ask the remote side for the file ID, and then
associate the two files with one another using the file ID.
With respect to rules based engines, you are FAR better off forcing
people to specify UNC names and then converting the drive letter path
into a UNC style name. But even then, you’ll need to do some serious
work to find the overlapping names and even then I can construct trivial
scenarios that will cause hideous problems for you (think “multiple
drive letters” and “mount points” on the server side and you will see
some of the problems inherent here.)
And that is why I always suggest to people that they use a server-side
assist. I CAN overcome all of these issues using a server side assist.
Barring that, you end up documenting restrictions on how people can
export the drives on their remote machines.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Friday, May 14, 2004 1:56 AM
To: ntfsd redirect
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
like i wrote earlier, what i want is to associate a drive letter to a
share for filename checking. say if h: is mapped to \server\share, i
would want to know h:\a.txt is actually \server\share\a.txt, and vice
versa.
this is because i need to use filename in the form of h:\a.txt for
checking against some rules specified in the said format. so if the file
is opened in the \server\share\a.txt format, i will need to translate
it to h:\a.txt. at the same time, i will also need the filename to be in
the \server\share\a.txt format in order to open it at the driver level.
so in rename operations where the filename can be in the \??\h:\a.txt,
i will need to know that h: is \server\share.
come to think of it, i can use \??\h:\a.txt to open the file in kernel,
right?
Ampsi
----- Original Message -----
From: “Ravisankar Pudipeddi”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 10:12
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
The way remote file systems map drive letters is by creating an NT
symbolic link from the drive letter to the redirector name thus:
\Device\LanmanRedirector;X:\server\share
(for drive letter connections to SMB shares for instance. Note, this is
just an example, it’s different if DFS is in picture, and don’t rely on
this, this kind of stuff can change between OS versions).
You should be able to look up the drive letter —> symbolic link target
via ZwOpenSymbolicObject & ZwQuerySymbolicObject.
By the time Ob parses & strips it off, what the redirector itself would
see is:
;X\server\share.
If relative opens are done against such an open of course, you wouldn’t
see any of this stuff in the relative file name.
Tree connections are different from opening the root directory of a
share. You probably don’t want to use them unless you understand what
they are for.
If the drive letter was associated with a DFS path, and you are
filtering above the RDR, you will not see the drive letter and stuff
because DFS translates - as DaniLo points out - to an underlying UNC
path. DFS itself does tree connections to UNC paths if explicit
credentials were supplied for a connection.
This is essentially a brain dump from my side since I really don’t know
what you want, hopefully you will find some answers above. If not you
probably want to really tell us
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 6:16 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
i am trying to associate a drive letter to a share for filename
checking.
when FILE_CREATE_TREE_CONNECTION is used in create for opening of a
share, the filename will consist of the drive letter as well as the
server share path.
however, i just found out that in the case i described below where
FILE_CREATE_TREE_CONNECTION is not used, there is no drive letter in any
of the filenames of any create related to the opening of the share. so
even if i can detect the opening of a share w/o
FILE_CREATE_TREE_CONNECTION, i still cannot get my drive letter.
is there any method to resolve a drive letter to a server share?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 00:21
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
What do you mean by the opening of shares? People can connect to a UNC
path
directly. Would you want to catch that?
It is not altogether clear what you are trying to accomplish. What is
it
the high-level goal that you are trying to achieve?
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 12:04 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
so is there another way to detect opening of shares other than relying
on
FILE_CREATE_TREE_CONNECTION?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 13, 2004 14:26
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
It sounds like DFS is in the picture. An open to a UNC name will go
through
DFS translation can hit the SMB redirector already translated.
In any case, you don’t necessarily needs a FILE_CREATE_TREE_CONNECTION
to
connect to a share.
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Wednesday, May 12, 2004 7:59 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FILE_CREATE_TREE_CONNECTION
hi,
i used the FILE_CREATE_TREE_CONNECTION flag to detect an open to a
network
share. however, i have encountered cases where a network share can be
opened
w/o specifying the flag. in these cases, the share seen in Windows
Explorer
is something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. how can i detect an
open
in these cases?
thanks.
Ampsi
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
For redirectors (SMB, WebDAV) and so on , the net use kicks off a tree
connect to \server\share.
For DFS don’t rely on a tree connect coming down for a net use. Your
filter is attached to LanmanRedirector right?
DFS translates logical paths to physical paths so if there are DFS links
on the path (or it’s a domain DFS root), the path that you see coming in
would be different than what the app issued.
If you are filtering right above the redirectors you can always tell
which file name the open is directed to, because even with drive
letters, once you strip the goo off you have a \server\share.… file
name. You really don’t need to fiddle with tree connections at all.
With current Windows versions, regarding your rules for filtering, you
are better off using physical paths than logical because you are
filtering below DFS. Since DFS links (and domain DFS roots) can point to
multiple targets, this means that you need to set the rules for all the
targets.
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Thursday, May 20, 2004 3:32 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
well, that’s precisely the problem. i need the drive letter for some
checks but network files can be opened w/o any drive letter. that is why
i implemented the drive mapping table based on trapping
FILE_CREATE_TREE_CONNECTION.
actually my scenario is quite simple. users access files on the servers
through drive mappings done through the login script. as the drive
mappings are already done for them during login, they will not be
opening files directly through the UNC name format. however, some
applications may sometimes use the UNC name format to access the files,
and this is the problem. before DFS, the drive mapping table can be
updated when the login script performed the mapping, as the mappings
will be done with the FILE_CREATE_TREE_CONNECTION flag. thus, my filter
is able to resolve from UNC to drive letter. with DFS, the mappings are
not done with the FILE_CREATE_TREE_CONNECTION flag, and the drive
mapping table is empty.
thus, my filter is unable to perform a resolution. so now this is the
problem.
well, even if i don’t use drive letters for checking, there will still
be a problem with DFS if my filter is to do filename checking. as
mentioned in my very first mail, the mapping seen in Windows Explorer is
something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. so in this case,
there is no match if the rules is set using “company.com.sg\home\ampsi”.
i don’t think it is appropriate to set the rule with
“company-server2.com.sg\users\sp\ampsi” as the purpose of DFS is to
encapsulate the actual servers with a common server path.
so, is there a way to the drive letter, say by sending a request to DFS?
Ampsi
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 20, 2004 17:33
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
I have no idea how you are trapping the UNC names from your example.
You keep focusing on drive letters, but the point here is that drive
letters are not required to access a remote resource.
For example, try writing a program of your own that opens a remote
resource (“\server\share\foo\bar.txt”) and see what you observe in your
filter. I do not expect that you will see a FILE_CREATE_TREE_CONNECTION
call in that instance, either.
Good luck!
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Wednesday, May 19, 2004 10:42 PM
To: ntfsd redirect
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
Tony,
What actually is important for for my filter to know is the drive
letter, as my filter checks some rules using the drive letter. to my
knowledge, there are only 2 broad ways to specify a filename for files
on remote shares. one is the “\x:\server\share\filename.extension”
format while the other is the “\server\share\filename.extension” format.
in the first format, i already can get the drive letter from the
filename. to handle the second format, i trap the
FILE_CREATE_TREE_CONNECTION call as the filename in the call is in the
“\x:\server\share” format. with this info, i can create a mapping table
from drive letter to “\server\share”.
if Y: is \server\bar and Z: is \server\foo, when \server\bar\file.txt
is opened, my filter will know file.txt comes from Y:, and when
\server\foo\bar\file.txt is opened, my filter will know file.txt comes
from Z:.
in addition, my filter prevents mulitple drive mappings to the same
\server\share to avoid drive letter confusion. of course, this can only
be done now as my filter traps the FILE_CREATE_TREE_CONNECTION flag. i
have also specified to the system admins not to create shares that are
within each other, such as in your example, as this will confuse the
filter as well.
so now with DFS, no create with FILE_CREATE_TREE_CONNECTION is called,
and thus my drive mapping table is empty. so what i hope to find is a
way for my filter to be able to fill up this mappin table.
Ampsi
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 17:23
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
Hi Ampsi,
There is a ptoential flaw in the mechanism you are using, because it
presumes that there is some unique structure to the name of the file.
However, consider the following scenario:
A server exports two shares by doing the following:
“net share foo=c:\foo”
“net share bar=c:\foo\bar”
A client then maps these:
“net use * \server\foo”
“net use * \server\bar”
Suppose that the first is assigned drive letter Z: and the second Y:
I then open the files:
Z:\bar\file.txt
Y:\file.txt
How will you associate these two files together? In addition, suppose a
client only maps the second one and then a user on that client machine
uses Explorer to browse the “Network Neighborhood” (which translates to
a UNC open) and browses via the first share. The UNC name now becomes
“\server\foo\bar\file.txt” and the drive letter name is “y:\file.txt”.
I mention this last case, because a simple technique for dealing with
this is to look at the drive letter in the object manager name space
(there are ZwXxx APIs for opening and reading object manager symbolic
link names). That drive letter will contain name information (the
format varies by version, but in XP, for example, it will map to
something like “;Y:00000000000144b4\server\bar” (of course, to find this
mapping you will need to look in “\Session<session>#>\DosDevices<session id><drive letter>”. The problem with this
technique is that it doesn’t work.
Indeed, the only reliable way of which I know to associate two remote
files with one another is to use a server-side assist. We’ve done that
here at OSR in the past - with a server side filter driver, you can
tunnel across the network, ask the remote side for the file ID, and then
associate the two files with one another using the file ID.
With respect to rules based engines, you are FAR better off forcing
people to specify UNC names and then converting the drive letter path
into a UNC style name. But even then, you’ll need to do some serious
work to find the overlapping names and even then I can construct trivial
scenarios that will cause hideous problems for you (think “multiple
drive letters” and “mount points” on the server side and you will see
some of the problems inherent here.)
And that is why I always suggest to people that they use a server-side
assist. I CAN overcome all of these issues using a server side assist.
Barring that, you end up documenting restrictions on how people can
export the drives on their remote machines.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Friday, May 14, 2004 1:56 AM
To: ntfsd redirect
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
like i wrote earlier, what i want is to associate a drive letter to a
share for filename checking. say if h: is mapped to \server\share, i
would want to know h:\a.txt is actually \server\share\a.txt, and vice
versa.
this is because i need to use filename in the form of h:\a.txt for
checking against some rules specified in the said format. so if the file
is opened in the \server\share\a.txt format, i will need to translate
it to h:\a.txt. at the same time, i will also need the filename to be in
the \server\share\a.txt format in order to open it at the driver level.
so in rename operations where the filename can be in the \??\h:\a.txt,
i will need to know that h: is \server\share.
come to think of it, i can use \??\h:\a.txt to open the file in kernel,
right?
Ampsi
----- Original Message -----
From: “Ravisankar Pudipeddi”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 10:12
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
The way remote file systems map drive letters is by creating an NT
symbolic link from the drive letter to the redirector name thus:
\Device\LanmanRedirector;X:\server\share
(for drive letter connections to SMB shares for instance. Note, this is
just an example, it’s different if DFS is in picture, and don’t rely on
this, this kind of stuff can change between OS versions).
You should be able to look up the drive letter —> symbolic link target
via ZwOpenSymbolicObject & ZwQuerySymbolicObject.
By the time Ob parses & strips it off, what the redirector itself would
see is:
;X\server\share.
If relative opens are done against such an open of course, you wouldn’t
see any of this stuff in the relative file name.
Tree connections are different from opening the root directory of a
share. You probably don’t want to use them unless you understand what
they are for.
If the drive letter was associated with a DFS path, and you are
filtering above the RDR, you will not see the drive letter and stuff
because DFS translates - as DaniLo points out - to an underlying UNC
path. DFS itself does tree connections to UNC paths if explicit
credentials were supplied for a connection.
This is essentially a brain dump from my side since I really don’t know
what you want, hopefully you will find some answers above. If not you
probably want to really tell us
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 6:16 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
i am trying to associate a drive letter to a share for filename
checking.
when FILE_CREATE_TREE_CONNECTION is used in create for opening of a
share, the filename will consist of the drive letter as well as the
server share path.
however, i just found out that in the case i described below where
FILE_CREATE_TREE_CONNECTION is not used, there is no drive letter in any
of the filenames of any create related to the opening of the share. so
even if i can detect the opening of a share w/o
FILE_CREATE_TREE_CONNECTION, i still cannot get my drive letter.
is there any method to resolve a drive letter to a server share?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 00:21
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
What do you mean by the opening of shares? People can connect to a UNC
path
directly. Would you want to catch that?
It is not altogether clear what you are trying to accomplish. What is
it
the high-level goal that you are trying to achieve?
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 12:04 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
so is there another way to detect opening of shares other than relying
on
FILE_CREATE_TREE_CONNECTION?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 13, 2004 14:26
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
It sounds like DFS is in the picture. An open to a UNC name will go
through
DFS translation can hit the SMB redirector already translated.
In any case, you don’t necessarily needs a FILE_CREATE_TREE_CONNECTION
to
connect to a share.
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Wednesday, May 12, 2004 7:59 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FILE_CREATE_TREE_CONNECTION
hi,
i used the FILE_CREATE_TREE_CONNECTION flag to detect an open to a
network
share. however, i have encountered cases where a network share can be
opened
w/o specifying the flag. in these cases, the share seen in Windows
Explorer
is something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. how can i detect an
open
in these cases?
thanks.
Ampsi
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Correction>
-----Original Message-----
From: Ravisankar Pudipeddi
Sent: Thursday, May 20, 2004 10:29 AM
To: ‘Windows File Systems Devs Interest List’
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
For the SMB redirector, the net use kicks off a tree connect to
\server\share.
For DFS don’t rely on a tree connect coming down for a net use. Your
filter is attached to LanmanRedirector right?
DFS translates logical paths to physical paths so if there are DFS links
on the path (or it’s a domain DFS root), the path that you see coming in
would be different than what the app issued.
If you are filtering right above the redirectors you can always tell
which file name the open is directed to, because even with drive
letters, once you strip the goo off you have a \server\share.… file
name. You really don’t need to fiddle with tree connections at all.
With current Windows versions, regarding your rules for filtering, you
are better off using physical paths than logical because you are
filtering below DFS. Since DFS links (and domain DFS roots) can point to
multiple targets, this means that you need to set the rules for all the
targets.
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Thursday, May 20, 2004 3:32 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
well, that’s precisely the problem. i need the drive letter for some
checks but network files can be opened w/o any drive letter. that is why
i implemented the drive mapping table based on trapping
FILE_CREATE_TREE_CONNECTION.
actually my scenario is quite simple. users access files on the servers
through drive mappings done through the login script. as the drive
mappings are already done for them during login, they will not be
opening files directly through the UNC name format. however, some
applications may sometimes use the UNC name format to access the files,
and this is the problem. before DFS, the drive mapping table can be
updated when the login script performed the mapping, as the mappings
will be done with the FILE_CREATE_TREE_CONNECTION flag. thus, my filter
is able to resolve from UNC to drive letter. with DFS, the mappings are
not done with the FILE_CREATE_TREE_CONNECTION flag, and the drive
mapping table is empty.
thus, my filter is unable to perform a resolution. so now this is the
problem.
well, even if i don’t use drive letters for checking, there will still
be a problem with DFS if my filter is to do filename checking. as
mentioned in my very first mail, the mapping seen in Windows Explorer is
something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. so in this case,
there is no match if the rules is set using “company.com.sg\home\ampsi”.
i don’t think it is appropriate to set the rule with
“company-server2.com.sg\users\sp\ampsi” as the purpose of DFS is to
encapsulate the actual servers with a common server path.
so, is there a way to the drive letter, say by sending a request to DFS?
Ampsi
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 20, 2004 17:33
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
I have no idea how you are trapping the UNC names from your example.
You keep focusing on drive letters, but the point here is that drive
letters are not required to access a remote resource.
For example, try writing a program of your own that opens a remote
resource (“\server\share\foo\bar.txt”) and see what you observe in your
filter. I do not expect that you will see a FILE_CREATE_TREE_CONNECTION
call in that instance, either.
Good luck!
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Wednesday, May 19, 2004 10:42 PM
To: ntfsd redirect
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
Tony,
What actually is important for for my filter to know is the drive
letter, as my filter checks some rules using the drive letter. to my
knowledge, there are only 2 broad ways to specify a filename for files
on remote shares. one is the “\x:\server\share\filename.extension”
format while the other is the “\server\share\filename.extension” format.
in the first format, i already can get the drive letter from the
filename. to handle the second format, i trap the
FILE_CREATE_TREE_CONNECTION call as the filename in the call is in the
“\x:\server\share” format. with this info, i can create a mapping table
from drive letter to “\server\share”.
if Y: is \server\bar and Z: is \server\foo, when \server\bar\file.txt
is opened, my filter will know file.txt comes from Y:, and when
\server\foo\bar\file.txt is opened, my filter will know file.txt comes
from Z:.
in addition, my filter prevents mulitple drive mappings to the same
\server\share to avoid drive letter confusion. of course, this can only
be done now as my filter traps the FILE_CREATE_TREE_CONNECTION flag. i
have also specified to the system admins not to create shares that are
within each other, such as in your example, as this will confuse the
filter as well.
so now with DFS, no create with FILE_CREATE_TREE_CONNECTION is called,
and thus my drive mapping table is empty. so what i hope to find is a
way for my filter to be able to fill up this mappin table.
Ampsi
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 17:23
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
Hi Ampsi,
There is a ptoential flaw in the mechanism you are using, because it
presumes that there is some unique structure to the name of the file.
However, consider the following scenario:
A server exports two shares by doing the following:
“net share foo=c:\foo”
“net share bar=c:\foo\bar”
A client then maps these:
“net use * \server\foo”
“net use * \server\bar”
Suppose that the first is assigned drive letter Z: and the second Y:
I then open the files:
Z:\bar\file.txt
Y:\file.txt
How will you associate these two files together? In addition, suppose a
client only maps the second one and then a user on that client machine
uses Explorer to browse the “Network Neighborhood” (which translates to
a UNC open) and browses via the first share. The UNC name now becomes
“\server\foo\bar\file.txt” and the drive letter name is “y:\file.txt”.
I mention this last case, because a simple technique for dealing with
this is to look at the drive letter in the object manager name space
(there are ZwXxx APIs for opening and reading object manager symbolic
link names). That drive letter will contain name information (the
format varies by version, but in XP, for example, it will map to
something like “;Y:00000000000144b4\server\bar” (of course, to find this
mapping you will need to look in “\Session<session>#>\DosDevices<session id><drive letter>”. The problem with this
technique is that it doesn’t work.
Indeed, the only reliable way of which I know to associate two remote
files with one another is to use a server-side assist. We’ve done that
here at OSR in the past - with a server side filter driver, you can
tunnel across the network, ask the remote side for the file ID, and then
associate the two files with one another using the file ID.
With respect to rules based engines, you are FAR better off forcing
people to specify UNC names and then converting the drive letter path
into a UNC style name. But even then, you’ll need to do some serious
work to find the overlapping names and even then I can construct trivial
scenarios that will cause hideous problems for you (think “multiple
drive letters” and “mount points” on the server side and you will see
some of the problems inherent here.)
And that is why I always suggest to people that they use a server-side
assist. I CAN overcome all of these issues using a server side assist.
Barring that, you end up documenting restrictions on how people can
export the drives on their remote machines.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Friday, May 14, 2004 1:56 AM
To: ntfsd redirect
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
like i wrote earlier, what i want is to associate a drive letter to a
share for filename checking. say if h: is mapped to \server\share, i
would want to know h:\a.txt is actually \server\share\a.txt, and vice
versa.
this is because i need to use filename in the form of h:\a.txt for
checking against some rules specified in the said format. so if the file
is opened in the \server\share\a.txt format, i will need to translate
it to h:\a.txt. at the same time, i will also need the filename to be in
the \server\share\a.txt format in order to open it at the driver level.
so in rename operations where the filename can be in the \??\h:\a.txt,
i will need to know that h: is \server\share.
come to think of it, i can use \??\h:\a.txt to open the file in kernel,
right?
Ampsi
----- Original Message -----
From: “Ravisankar Pudipeddi”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 10:12
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
The way remote file systems map drive letters is by creating an NT
symbolic link from the drive letter to the redirector name thus:
\Device\LanmanRedirector;X:\server\share
(for drive letter connections to SMB shares for instance. Note, this is
just an example, it’s different if DFS is in picture, and don’t rely on
this, this kind of stuff can change between OS versions).
You should be able to look up the drive letter —> symbolic link target
via ZwOpenSymbolicObject & ZwQuerySymbolicObject.
By the time Ob parses & strips it off, what the redirector itself would
see is:
;X\server\share.
If relative opens are done against such an open of course, you wouldn’t
see any of this stuff in the relative file name.
Tree connections are different from opening the root directory of a
share. You probably don’t want to use them unless you understand what
they are for.
If the drive letter was associated with a DFS path, and you are
filtering above the RDR, you will not see the drive letter and stuff
because DFS translates - as DaniLo points out - to an underlying UNC
path. DFS itself does tree connections to UNC paths if explicit
credentials were supplied for a connection.
This is essentially a brain dump from my side since I really don’t know
what you want, hopefully you will find some answers above. If not you
probably want to really tell us
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 6:16 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
i am trying to associate a drive letter to a share for filename
checking.
when FILE_CREATE_TREE_CONNECTION is used in create for opening of a
share, the filename will consist of the drive letter as well as the
server share path.
however, i just found out that in the case i described below where
FILE_CREATE_TREE_CONNECTION is not used, there is no drive letter in any
of the filenames of any create related to the opening of the share. so
even if i can detect the opening of a share w/o
FILE_CREATE_TREE_CONNECTION, i still cannot get my drive letter.
is there any method to resolve a drive letter to a server share?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 00:21
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
What do you mean by the opening of shares? People can connect to a UNC
path directly. Would you want to catch that?
It is not altogether clear what you are trying to accomplish. What is
it the high-level goal that you are trying to achieve?
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 12:04 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
so is there another way to detect opening of shares other than relying
on FILE_CREATE_TREE_CONNECTION?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 13, 2004 14:26
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
It sounds like DFS is in the picture. An open to a UNC name will go
through DFS translation can hit the SMB redirector already translated.
In any case, you don’t necessarily needs a FILE_CREATE_TREE_CONNECTION
to connect to a share.
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Wednesday, May 12, 2004 7:59 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FILE_CREATE_TREE_CONNECTION
hi,
i used the FILE_CREATE_TREE_CONNECTION flag to detect an open to a
network share. however, i have encountered cases where a network share
can be opened w/o specifying the flag. in these cases, the share seen in
Windows Explorer is something like “company.com.sg\home\ampsi” but the
path seen in the kernel is “company-server2.com.sg\users\sp\ampsi”. how
can i detect an open in these cases?
thanks.
Ampsi
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
well, if my rules use physical paths, it will have to be changed if there
are different config.
since DFS translates logical to physical paths, does it provide some
interface to retrieve this info?
Ampsi
----- Original Message -----
From: “Ravisankar Pudipeddi”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 21, 2004 01:32
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
Correction>
-----Original Message-----
From: Ravisankar Pudipeddi
Sent: Thursday, May 20, 2004 10:29 AM
To: ‘Windows File Systems Devs Interest List’
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
For the SMB redirector, the net use kicks off a tree connect to
\server\share.
For DFS don’t rely on a tree connect coming down for a net use. Your
filter is attached to LanmanRedirector right?
DFS translates logical paths to physical paths so if there are DFS links
on the path (or it’s a domain DFS root), the path that you see coming in
would be different than what the app issued.
If you are filtering right above the redirectors you can always tell
which file name the open is directed to, because even with drive
letters, once you strip the goo off you have a \server\share.… file
name. You really don’t need to fiddle with tree connections at all.
With current Windows versions, regarding your rules for filtering, you
are better off using physical paths than logical because you are
filtering below DFS. Since DFS links (and domain DFS roots) can point to
multiple targets, this means that you need to set the rules for all the
targets.
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Thursday, May 20, 2004 3:32 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
well, that’s precisely the problem. i need the drive letter for some
checks but network files can be opened w/o any drive letter. that is why
i implemented the drive mapping table based on trapping
FILE_CREATE_TREE_CONNECTION.
actually my scenario is quite simple. users access files on the servers
through drive mappings done through the login script. as the drive
mappings are already done for them during login, they will not be
opening files directly through the UNC name format. however, some
applications may sometimes use the UNC name format to access the files,
and this is the problem. before DFS, the drive mapping table can be
updated when the login script performed the mapping, as the mappings
will be done with the FILE_CREATE_TREE_CONNECTION flag. thus, my filter
is able to resolve from UNC to drive letter. with DFS, the mappings are
not done with the FILE_CREATE_TREE_CONNECTION flag, and the drive
mapping table is empty.
thus, my filter is unable to perform a resolution. so now this is the
problem.
well, even if i don’t use drive letters for checking, there will still
be a problem with DFS if my filter is to do filename checking. as
mentioned in my very first mail, the mapping seen in Windows Explorer is
something like “company.com.sg\home\ampsi” but the path seen in the
kernel is “company-server2.com.sg\users\sp\ampsi”. so in this case,
there is no match if the rules is set using “company.com.sg\home\ampsi”.
i don’t think it is appropriate to set the rule with
“company-server2.com.sg\users\sp\ampsi” as the purpose of DFS is to
encapsulate the actual servers with a common server path.
so, is there a way to the drive letter, say by sending a request to DFS?
Ampsi
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 20, 2004 17:33
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
I have no idea how you are trapping the UNC names from your example.
You keep focusing on drive letters, but the point here is that drive
letters are not required to access a remote resource.
For example, try writing a program of your own that opens a remote
resource (“\server\share\foo\bar.txt”) and see what you observe in your
filter. I do not expect that you will see a FILE_CREATE_TREE_CONNECTION
call in that instance, either.
Good luck!
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Wednesday, May 19, 2004 10:42 PM
To: ntfsd redirect
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
Tony,
What actually is important for for my filter to know is the drive
letter, as my filter checks some rules using the drive letter. to my
knowledge, there are only 2 broad ways to specify a filename for files
on remote shares. one is the “\x:\server\share\filename.extension”
format while the other is the “\server\share\filename.extension” format.
in the first format, i already can get the drive letter from the
filename. to handle the second format, i trap the
FILE_CREATE_TREE_CONNECTION call as the filename in the call is in the
“\x:\server\share” format. with this info, i can create a mapping table
from drive letter to “\server\share”.
if Y: is \server\bar and Z: is \server\foo, when \server\bar\file.txt
is opened, my filter will know file.txt comes from Y:, and when
\server\foo\bar\file.txt is opened, my filter will know file.txt comes
from Z:.
in addition, my filter prevents mulitple drive mappings to the same
\server\share to avoid drive letter confusion. of course, this can only
be done now as my filter traps the FILE_CREATE_TREE_CONNECTION flag. i
have also specified to the system admins not to create shares that are
within each other, such as in your example, as this will confuse the
filter as well.
so now with DFS, no create with FILE_CREATE_TREE_CONNECTION is called,
and thus my drive mapping table is empty. so what i hope to find is a
way for my filter to be able to fill up this mappin table.
Ampsi
----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 17:23
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
Hi Ampsi,
There is a ptoential flaw in the mechanism you are using, because it
presumes that there is some unique structure to the name of the file.
However, consider the following scenario:
A server exports two shares by doing the following:
“net share foo=c:\foo”
“net share bar=c:\foo\bar”
A client then maps these:
“net use * \server\foo”
“net use * \server\bar”
Suppose that the first is assigned drive letter Z: and the second Y:
I then open the files:
Z:\bar\file.txt
Y:\file.txt
How will you associate these two files together? In addition, suppose a
client only maps the second one and then a user on that client machine
uses Explorer to browse the “Network Neighborhood” (which translates to
a UNC open) and browses via the first share. The UNC name now becomes
“\server\foo\bar\file.txt” and the drive letter name is “y:\file.txt”.
I mention this last case, because a simple technique for dealing with
this is to look at the drive letter in the object manager name space
(there are ZwXxx APIs for opening and reading object manager symbolic
link names). That drive letter will contain name information (the
format varies by version, but in XP, for example, it will map to
something like “;Y:00000000000144b4\server\bar” (of course, to find this
mapping you will need to look in “\Session<session>#>\DosDevices<session id><drive letter>”. The problem with this
technique is that it doesn’t work.
Indeed, the only reliable way of which I know to associate two remote
files with one another is to use a server-side assist. We’ve done that
here at OSR in the past - with a server side filter driver, you can
tunnel across the network, ask the remote side for the file ID, and then
associate the two files with one another using the file ID.
With respect to rules based engines, you are FAR better off forcing
people to specify UNC names and then converting the drive letter path
into a UNC style name. But even then, you’ll need to do some serious
work to find the overlapping names and even then I can construct trivial
scenarios that will cause hideous problems for you (think “multiple
drive letters” and “mount points” on the server side and you will see
some of the problems inherent here.)
And that is why I always suggest to people that they use a server-side
assist. I CAN overcome all of these issues using a server side assist.
Barring that, you end up documenting restrictions on how people can
export the drives on their remote machines.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ampsi
Sent: Friday, May 14, 2004 1:56 AM
To: ntfsd redirect
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
like i wrote earlier, what i want is to associate a drive letter to a
share for filename checking. say if h: is mapped to \server\share, i
would want to know h:\a.txt is actually \server\share\a.txt, and vice
versa.
this is because i need to use filename in the form of h:\a.txt for
checking against some rules specified in the said format. so if the file
is opened in the \server\share\a.txt format, i will need to translate
it to h:\a.txt. at the same time, i will also need the filename to be in
the \server\share\a.txt format in order to open it at the driver level.
so in rename operations where the filename can be in the \??\h:\a.txt,
i will need to know that h: is \server\share.
come to think of it, i can use \??\h:\a.txt to open the file in kernel,
right?
Ampsi
----- Original Message -----
From: “Ravisankar Pudipeddi”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 10:12
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
The way remote file systems map drive letters is by creating an NT
symbolic link from the drive letter to the redirector name thus:
\Device\LanmanRedirector;X:\server\share
(for drive letter connections to SMB shares for instance. Note, this is
just an example, it’s different if DFS is in picture, and don’t rely on
this, this kind of stuff can change between OS versions).
You should be able to look up the drive letter —> symbolic link target
via ZwOpenSymbolicObject & ZwQuerySymbolicObject.
By the time Ob parses & strips it off, what the redirector itself would
see is:
;X\server\share.
If relative opens are done against such an open of course, you wouldn’t
see any of this stuff in the relative file name.
Tree connections are different from opening the root directory of a
share. You probably don’t want to use them unless you understand what
they are for.
If the drive letter was associated with a DFS path, and you are
filtering above the RDR, you will not see the drive letter and stuff
because DFS translates - as DaniLo points out - to an underlying UNC
path. DFS itself does tree connections to UNC paths if explicit
credentials were supplied for a connection.
This is essentially a brain dump from my side since I really don’t know
what you want, hopefully you will find some answers above. If not you
probably want to really tell us
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 6:16 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
i am trying to associate a drive letter to a share for filename
checking.
when FILE_CREATE_TREE_CONNECTION is used in create for opening of a
share, the filename will consist of the drive letter as well as the
server share path.
however, i just found out that in the case i described below where
FILE_CREATE_TREE_CONNECTION is not used, there is no drive letter in any
of the filenames of any create related to the opening of the share. so
even if i can detect the opening of a share w/o
FILE_CREATE_TREE_CONNECTION, i still cannot get my drive letter.
is there any method to resolve a drive letter to a server share?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 14, 2004 00:21
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
What do you mean by the opening of shares? People can connect to a UNC
path directly. Would you want to catch that?
It is not altogether clear what you are trying to accomplish. What is
it the high-level goal that you are trying to achieve?
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Thursday, May 13, 2004 12:04 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_CREATE_TREE_CONNECTION
so is there another way to detect opening of shares other than relying
on FILE_CREATE_TREE_CONNECTION?
Ampsi
----- Original Message -----
From: “Danilo Almeida”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, May 13, 2004 14:26
Subject: RE: [ntfsd] FILE_CREATE_TREE_CONNECTION
It sounds like DFS is in the picture. An open to a UNC name will go
through DFS translation can hit the SMB redirector already translated.
In any case, you don’t necessarily needs a FILE_CREATE_TREE_CONNECTION
to connect to a share.
- Danilo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ho Mun Chuen
Sent: Wednesday, May 12, 2004 7:59 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FILE_CREATE_TREE_CONNECTION
hi,
i used the FILE_CREATE_TREE_CONNECTION flag to detect an open to a
network share. however, i have encountered cases where a network share
can be opened w/o specifying the flag. in these cases, the share seen in
Windows Explorer is something like “company.com.sg\home\ampsi” but the
path seen in the kernel is “company-server2.com.sg\users\sp\ampsi”. how
can i detect an open in these cases?
thanks.
Ampsi
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com