windows 2000-xp ifs faqs.htm

ifs faq,编写文件系统驱动不可缺少的

            stored in the registry, or by explicit requests to load the driver 
            via the ZwLoadDriver API (which is documented in the Windows XP IFS 
            Kit). <BR><BR>While it is possible to build a Windows 2000-style 
            file system driver (which utilizes an AddDevice entry point) none of 
            the existing Windows 2000 file system function in this manner. Thus, 
            they are neither installed using INF scripts, nor does the plug and 
            play manager start them.</SPAN> </P></TD>
          <TD vAlign=top width="10%">&nbsp;</TD></TR></TBODY></TABLE><!--  Enb Table for - Q4 Answer --><A 
      name=Q5></A><!--  Begin Table for - Q5 Answer -->
      <TABLE border=0 cellPadding=0 cellSpacing=0 width="100%">
        <TBODY>
        <TR>
          <TD colSpan=3>
            <HR SIZE=1>
            <SPAN class=textbold>Q5 How is the file system's device object 
            found?</SPAN> <BR><BR></TD></TR>
        <TR>
          <TD align=middle vAlign=top width="20%">&nbsp;</TD>
          <TD width="5%">&nbsp;</TD>
          <TD align=left vAlign=top width="60%">
            <P><SPAN class=text>Each time a user performs an open operation (via 
            ZwCreateFile) they must either specify an absolute path name or they 
            must specify a path name relative to an existing open file or 
            directory. <BR><BR>In the case of a relative open, the I/O Manager 
            "knows" to which device it should send the requests, because the 
            existing open file or directory already references the correct file 
            system device instance. Thus, the request can be sent directly to 
            that device. <BR><BR>In the case of an absolute open, the I/O 
            Manager must first start by parsing the name via the Object Manager. 
            The Object Manager resolves a portion of the name that leads to a 
            device object and then passes the balance of the name (the portion 
            that has not yet been resolved) back to the I/O Manager, along with 
            a pointer to the device object it located during its portion of name 
            resolution. <BR><BR>The I/O Manager then examines the device object. 
            If the device object has a valid pointer to a volume parameter block 
            (VPB), the I/O Manager uses the DeviceObject field of the VPB to 
            find the correct file system device object. If the device object 
            does not have a valid VPB pointer, then the I/O Manager sends the 
            IRP_MJ_CREATE request directly to the device driver for the device 
            object passed in by the object manager. <BR><BR>For example, a 
            physical media file system volume is located via the VPB. If, for 
            instance, an application program attempts to open some file, say 
            "c:\fred\bob.txt", this name is translated into its Windows 
            NT/2000/XP equivalent name (via the Win32 CreateFile API call's 
            implementation) "\DosDevices\c:\fred\bob.txt". This name, when 
            passed to the I/O Manager must then be passed off to the object 
            manager in order to locate the correct physical media device object. 
            The object manager begins by attempting to locate the "DosDevices" 
            entry. This entry is a symbolic link to the ?? directory (which, in 
            turn, is a special directory, whose contents can vary on a 
            per-process basis). This causes the name to be reconstructed using 
            the new name. Parsing that new name then begins again. Thus, this 
            name becomes "\??\C:\fred\bob.txt". The parsing for ?? locates the 
            correct directory (the one that can vary on a per-process basis) and 
            then in that directory it finds the "c:" entry. This is yet another 
            symbolic link. The contents of this will vary from one computer to 
            another, depending upon its configuration, but it would typically be 
            some new name such as (this from a real Windows XP system) 
            "\Device\HarddiskVolume1". Thus, the name being parsed has now been 
            reworked so that it is "\Device\HarddiskVolume1\fred\bob.txt". 
            Initiating a parse with this name we find the Device directory and 
            then the HarddiskVolume1 device object within that directory. 
            <BR><BR>This device object, along with the balance of the name, is 
            then passed into the I/O Manager. The I/O Manager then examines the 
            device object in question. Using the DeviceTree utility (available 
            from OSR, and also scheduled for inclusion in the Windows XP DDK), 
            we can see that this device object has a VPB structure that in turn 
            points to the correct file system device instance. Thus, the name 
            passed by the object manager to the FSD in this instance was 
            "\fred\bob.txt" and the file system's device object found via the 
            VPB will be passed to its IRP_MJ_CREATE dispatch entry point. 
            <BR><BR>Had we performed the same analysis using a different drive 
            letter, such as the "I:" drive, which maps to a network share, we 
            would have followed similar parsing logic until we found the device 
            name, which in this case the name on our sample system was 
            "\Device\LanmanRedirector\;I:0\server\c$". However, when the I/O 
            Manager examines the device object (for "\Device\LanmanRedirector") 
            it will not find a VPB. Thus, it will pass the balance of the name 
            to the IRP_MJ_CREATE handler of this device directly. Note that the 
            name passed in this case would be quite different: 
            "\;I:0\server\c$\fred\bob.txt".</SPAN> </P></TD>
          <TD vAlign=top width="10%">&nbsp;</TD></TR></TBODY></TABLE><!--  Enb Table for - Q5 Answer --><A 
      name=Q6></A><!--  Begin Table for - Q6 Answer -->
      <TABLE border=0 cellPadding=0 cellSpacing=0 width="100%">
        <TBODY>
        <TR>
          <TD colSpan=3>
            <HR SIZE=1>
            <SPAN class=textbold>Q6 What's the right way to cancel a CREATE 
            request in my filter driver?</SPAN> <BR><BR></TD></TR>
        <TR>
          <TD align=middle vAlign=top width="20%">&nbsp;</TD>
          <TD width="5%">&nbsp;</TD>
          <TD align=left vAlign=top width="60%">
            <P><SPAN class=text>A file system filter driver will sometimes need 
            to pass an IRP_MJ_CREATE request to the underlying file system and 
            determine (in its completion routine for IRP_MJ_CREATE) whether or 
            not the operation should be successful. The issue becomes the fact 
            that the file object has now been declared to the underlying FSD. If 
            the filter driver fails the IRP_MJ_CREATE operation it will cause a 
            memory leak because the FSD will not know the file object is no 
            longer in use. <BR><BR>For Windows 2000 and Windows XP a file system 
            filter driver can use the IoCancelOpen API. For earlier versions of 
            Windows NT, equivalent functionality is achieved by: <BR><BR>- 
            Setting the FO_HANDLE_CREATED field in the file object; and<BR>- 
            Sending an IRP_MJ_CLEANUP to the underlying FSD; and<BR>- Sending an 
            IRP_MJ_CLOSE operation to the underlying FSD. <BR><BR>These I/O 
            operations should be performed synchronously. Once these have all 
            been completed, the status of the original IRP must be set to an 
            error value and the I/O operation completed.</SPAN> </P></TD>
          <TD vAlign=top width="10%">&nbsp;</TD></TR></TBODY></TABLE><!--  Enb Table for - Q6 Answer --><A 
      name=Q7></A><!--  Begin Table for - Q7 Answer -->
      <TABLE border=0 cellPadding=0 cellSpacing=0 width="100%">
        <TBODY>
        <TR>
          <TD colSpan=3>
            <HR SIZE=1>
            <SPAN class=textbold>Q7 How do I deal with file-sharing issues in my 
            filter driver?</SPAN> <BR><BR></TD></TR>
        <TR>
          <TD align=middle vAlign=top width="20%">&nbsp;</TD>
          <TD width="5%">&nbsp;</TD>
          <TD align=left vAlign=top width="60%">
            <P><SPAN class=text>File sharing semantics are often an unforeseen 
            complication for file system filter drivers. This is because filter 
            drivers often wish to create separate handles against the file so 
            that they can perform operations against the file, independent of 
            the application-initiated request to access the file. For example, 
            an on-access virus scanner might wish to read an executable in order 
            to scan it - this requires read access, while execution does not 
            require read access. <BR><BR>Regardless of the reason, the "problem" 
            that many file system filter drivers have is that when they attempt 
            to open the file, they must be able to handle file-sharing issues. 
            Specifically, if another application opens the file, it might 
            specify exclusive access to the file. It may be critical to the 
            function of the filter driver that it be allowed to access the file 
            even though normal file sharing semantics would reject the access 
            request. There are a few techniques that a file system filter driver 
            can use to "circumvent" file sharing semantics: <BR><BR>- The filter 
            driver can implement the file sharing internally in the filter 
            driver; in this case it always asked the underlying FSD for 
            full-sharing of the file and enforces the sharing at its level; 
            or<BR>- The filter driver can use memory mapping to access the file; 
            or<BR>- The filter driver can build IRPs and access the file 
            directly; <BR><BR>While it is possible for a file system filter 
            driver to implement the file sharing semantics internally within the 
            file system filter driver; it is often the most difficult situation 
            because of the complex nature of the sharing semantics. To properly 
            track sharing state, the file system must track (on a per-file 
            basis) the current sharing state of the file. Typically, this is 
            done to mirror the behavior of the FAT file system example in the 
            IFS Kit. Thus, when the file is opened, the sharing is managed by 
            using IoCheckShareAccess and/or IoUpdateShareAccess. When the user 
            closes the file (as specified by the IRP_MJ_CLEANUP operation) the 
            filter removes the share access (IoRemoveShareAccess) so that 
            subsequent operations to access the file succeed. <BR><BR>In 
            computing share access there are two important elements: <BR><BR>- 
            The access requested for the specific open instance of the file, 
            which is recorded in the file object; and<BR>- The share access 
            allowed by existing applications using the file. <BR><BR>The actual 
            implementation of this can be somewhat complicated, which is why it 
            is generally best to allow the FSD to manage this, or to use the I/O 
            Manager routines. <BR><BR>A second approach is to keep in mind that 
            the section object for a file can always be used to memory map the 
            file. <BR><BR>A third approach is to build read and write IRPs 
            directly. Because security checks (including whether or not a 
            read/write is allowed) are done in the I/O Manager before the 
            operation is passed to the file system. Thus, the filter driver can 
            perform I/O operations against a file object that was not opened for 
            read or write access, simply by constructing read and write IRPs 
            within the filter driver itself.</SPAN> </P></TD>
          <TD vAlign=top width="10%">&nbsp;</TD></TR></TBODY></TABLE><!--  Enb Table for - Q7 Answer --><A 
      name=Q8></A><!--  Begin Table for - Q8 Answer -->
      <TABLE border=0 cellPadding=0 cellSpacing=0 width="100%">
        <TBODY>
        <TR>
          <TD colSpan=3>
            <HR SIZE=1>
            <SPAN class=textbold>Q8 What's the proper way to install my file 
            system or file system filter driver?</SPAN> <BR><BR></TD></TR>
        <TR>
          <TD align=middle vAlign=top width="20%">&nbsp;</TD>
          <TD width="5%">&nbsp;</TD>
          <TD align=left vAlign=top width="60%">
            <P><SPAN class=text>Typically, a file system driver is a legacy 
            driver. As such, it is installed by using the Service Control 
            Manager, or directly making changes to the registry. A file system 
            filter driver normally installs in a separate fashion, although this 
            will change as the Windows XP team begins to add WHQL certification 
            mechanisms for certain types of file system filter drivers. For such 
            drivers, they will be required to utilize INF scripts. <BR><BR>In 
            addition, it is possible to build a plug-and-play "type" file 
            system. In such a case, it is possible to build an INF file for such 
            a driver. However, there are no existing samples of how to achieve 
            this.</SPAN> </P></TD>
          <TD vAlign=top width="10%">&nbsp;</TD></TR></TBODY></TABLE><!--  Enb Table for - Q8 Answer --><A 
      name=Q9></A><!--  Begin Table for - Q9 Answer -->
      <TABLE border=0 cellPadding=0 cellSpacing=0 width="100%">
        <TBODY>
        <TR>
          <TD colSpan=3>
            <HR SIZE=1>
            <SPAN class=textbold>Q9 Does WHQL logo file systems or file system 
            filter drivers?</SPAN> <BR><BR></TD></TR>
        <TR>
          <TD align=middle vAlign=top width="20%">&nbsp;</TD>
          <TD width="5%">&nbsp;</TD>
          <TD align=left vAlign=top width="60%">
            <P><SPAN class=text>Not at the present time. However, WHQL is 
            working on a plan for the future that will provide testing and 
            certification for certain types of file system filter drivers. The 
            first target file system filter drivers for certification will be 
            anti-virus filters.</SPAN> </P></TD>
          <TD vAlign=top width="10%">&nbsp;</TD></TR></TBODY></TABLE><!--  Enb Table for - Q9 Answer --><A 
      name=Q10></A><!--  Begin Table for - Q10 Answ