My team is attempting to write a utility that will let the user work
transparently with a folder of files that can reside on either the
local disk or a remote server.
We are fairly new to Windows driver development, so we wanted to see
whether our plan to implement this was on the right track. We intend
to use IFS to trap reads and writes and a userspace utility to
make decisions about whether files should be stored locally or
remotely. The scenario for a trapped “read” call would go like this:
Our filter driver monitors a certain directory.
The filter driver catches a “read” call for a particular file.
The driver postpones the IRP(s) associated with the read & notifies the
user-space program of the read.
The userspace program decides whether the read can continue normally
(by being passed down the FS stack) or whether an alternate file
must be retrieved from the Internet.
The userspace program tells the driver if the read can continue
normally; otherwise, it tells the driver to continue postponing
the IRP(s) until the new file can be downloaded.
If the driver was instructed to continue normally, the userspace
program and the filter driver are now finished.
Otherwise…
The userspace program downloads the alternate file and replaces the
on-disk version of the file with the downloaded file.
The userspace program notifies the driver that it is finished and it
can continue processing the held IRP(s). The userspace program is
now finished.
The driver continues by modifying the IRP(s) so that it refers to
the new file and passes the IRP(s) on to the next filter. The
driver is now finished.
We have a few specific questions:
Can the IRP(s) be safely held in a thread during a potentially
long download?
Does the userspace program have permission to modify/delete the file
referenced by the IRP(s) we’re holding in the driver?
We are planning to delete and replace the old file with a new file of
the same name while holding the old file’s IRP(s) in the driver. Will
we need to update the IRP(s) after we’ve replaced the file in order to
pass it to the next filter in the stack? Alternately, if we just
modify the file would we have to update the IRP(s)?
Can the IRP(s) be safely held in a thread during a potentially
long download?
You might want to lock at some network file system implementations,
I dont think this is the best ideea you could have.
> 2. Does the userspace program have permission to modify/delete the file
> referenced by the IRP(s) we’re holding in the driver?
Talking about permissions , it might or it might not have permission to MARK
a file for deletion. Deleting a file on disk is done by setting a special
information on it
called dispozition information. The actual delete operation takes places
when the file system
receives a IRP_MJ_CLOSE for the last file object which is associated the
file on the disk.
So, as long as you held any references to a file objects, delete opeartion
is just pending.
This has some other implications , as well.
We are planning to delete and replace the old file with a new file of
the same name while holding the old file’s IRP(s) in the driver. Will
we need to update the IRP(s) after we’ve replaced the file in order to
pass it to the next filter in the stack? Alternately, if we just
modify the file would we have to update the IRP(s)?
As outlined , a delete opeartion takes places only on close. So you cant
just delete / replace /
reuse original IRPs.
You can, however , truncate the file to size 0, and write new data to it.
I think you might want to think the design a bit more. Look at various
network file system
implementations and design guidelines , they might throw in usefull ideeas.
Regards, Dan
“jake” wrote in message news:xxxxx@ntfsd… > > Hi all, > > My team is attempting to write a utility that will let the user work > transparently with a folder of files that can reside on either the > local disk or a remote server. > > We are fairly new to Windows driver development, so we wanted to see > whether our plan to implement this was on the right track. We intend > to use IFS to trap reads and writes and a userspace utility to > make decisions about whether files should be stored locally or > remotely. The scenario for a trapped “read” call would go like this: > > - Our filter driver monitors a certain directory. > - The filter driver catches a “read” call for a particular file. > - The driver postpones the IRP(s) associated with the read & notifies the > user-space program of the read. > - The userspace program decides whether the read can continue normally > (by being passed down the FS stack) or whether an alternate file > must be retrieved from the Internet. > - The userspace program tells the driver if the read can continue > normally; otherwise, it tells the driver to continue postponing > the IRP(s) until the new file can be downloaded. > - If the driver was instructed to continue normally, the userspace > program and the filter driver are now finished. > > Otherwise… > > - The userspace program downloads the alternate file and replaces the > on-disk version of the file with the downloaded file. > - The userspace program notifies the driver that it is finished and it > can continue processing the held IRP(s). The userspace program is > now finished. > - The driver continues by modifying the IRP(s) so that it refers to > the new file and passes the IRP(s) on to the next filter. The > driver is now finished. > > We have a few specific questions: > > 1. Can the IRP(s) be safely held in a thread during a potentially > long download? > 2. Does the userspace program have permission to modify/delete the file > referenced by the IRP(s) we’re holding in the driver? > 3. We are planning to delete and replace the old file with a new file of > the same name while holding the old file’s IRP(s) in the driver. Will > we need to update the IRP(s) after we’ve replaced the file in order to > pass it to the next filter in the stack? Alternately, if we just > modify the file would we have to update the IRP(s)? > > Thank you all for your help, > > Jake > >