How does your filter decide that it wants to re-directed a file. If it is
based on some path name matching, are you taking into account relative opens
(RelatedFileObject != NULL), which SRV uses, when you construct the name?
I’m sure the IRP is passing through your filter and I’m just guessing about
your filter’s criteria for file re-direction.
/ted
-----Original Message-----
From: Shangwu [mailto:xxxxx@cox.net]
Sent: Friday, January 28, 2005 11:43 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] question about redirect network access (Thanks Tony and
Ken)
Thank you for your very important hints. I am checking my code now to look
for something wrong.
If I run debug of sfilter, all requests from network are captured by it. Let
me show you the scenario below. Probably you can provide some important
suggestions.
Our system moves a file - c:\somedir1\file1 to another location
d:\somedir2\file2.
The original file - file1 is replaced by a reparse point that points file2.
If I open file1 from the same computer, everything is fine. The filter will
catch the request and redirect the request to file2 in another location. But
If I open file1 from another compuer (c:\somedir1 is shared on the network),
an error message - “The file can not be accessed by the system” will be
showed on that computer. Because my filter cannot capture the request in its
create_routine.
I am not sure this problem is caused by my filter or some security related.
Best regards,
Shangwu
“Tony Mason” wrote in message news:xxxxx@ntfsd… SRV
(LanMan Server) is (from the file system perspective) an “application”. It
CALLS the file systems via their upper edge interface. MRXSMB (LanMan
Client) is a file system - it supports applications that call the file
systems API.
If your filter sits on top of NTFS, it sees calls from SRV (the
“application”). If your filter sits on top of MRXSMB, it sees calls from
applications accessing “network drives”.
So, if the request is coming “from another machine on the network” then it
is originating with SRV, then going through your filter and finally to the
underlying file system. If your filter is not seeing them, you have an
implementation problem within your filter driver. There are no “secret
handshake” interfaces. SRV, for all it can be painfully challenging as a
consumer of the file system services, is reasonably well behaved in this
regard.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April 4,
2004 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Shangwu
Sent: Thursday, January 27, 2005 4:45 PM
To: ntfsd redirect
Subject: [ntfsd] question about redirect network access
Hello,
My filter driver is implemented to redirect an open file request
(IRP_MJ_CREATE) to another location by returning STATUS_REPARSE if the file
points to another file. The filter driver attaches to all NTFS volumes at
boot time. Now I have a problem for network access. If an open file request
comes from another computer on the network, the filter driver can not catch
the request at all. Does the filter have to attach to
\Device\LanmanRedirector, LanmanServer or something else? My filter driver
was implemented based on sfilter of IFSkit. If my filter needs to attach to
LanmanServer, what is the best time and where is the attach point?
Thank you very much if you can post any response.
Shangwu
—
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@livevault.com To unsubscribe
send a blank email to xxxxx@lists.osr.com