Compartir a través de

7 Appendix B: Product Behavior

  • Artículo

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

  • Windows 2000 operating system

  • Windows Server 2003 operating system

  • Windows XP operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 1.3: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: The user on M0 indicates a desire to keep information about F1.txt by creating a Shell shortcut. The Shell shortcut is a file stored on M0 that holds the UNC, MachineID, FileLocation, and FileID for F1.txt.

<2> Section 1.3: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: The user initiates a request to open the file by activating the Shell shortcut that was created to store information about the file, F1.txt.

<3> Section 1.3: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: After storing the new FileLocation and UNC in the Shell shortcut file, the Shell shortcut implementation opens the file; for example, the shortcut implementation loads the file into the Notepad program. None of this processing is visible to end users. End users simply activate the Shell shortcut by double-clicking it, and then view the contents of the file in Notepad.

<4> Section 3.1.4.1: Windows Server 2003 implements this restriction.

<5> Section 3.1.4.1: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: When the server is busy processing several requests, it uses the priority field to determine which requests to process and which requests to reject with a TRK_E_SERVER_TOO_BUSY return value.

<6> Section 3.1.4.1: For example, in all versions of Windows listed in the supported products list in Appendix B: Product Behavior, the RequestMachine is determined as follows:

  • The client identity is obtained, as described in [MS-RPCE], section 3.3.3.4.3, and the client identity is used to obtain the user principal name (UPN).

  • That client identity is used to access the client's user object, described in section 3.1.1.

  • If that user object has a UserAccountControl with neither UF_SERVER_TRUST_ACOUNT nor UF_WORKSTATION_TRUST_ACCOUNT set, or if the user account name of the UPN does not end in a dollar sign ($), the request fails. For more information on the user object and UserAccountControl, see section 3.1.1.

  • The post-fix dollar sign ($) is removed from the user account name of the UPN, and then the name is used as the value of the RequestMachine.

<7> Section 3.1.4.4: Windows 2000: The protocol uses the LnkSvrMessageCallback to return information to the client if the SYNC_VOLUMES request includes a CREATE_VOLUME subrequest.

Windows Server 2003: The callback is not used; information is provided to the client on return from the LnkSvrMessage request.

<8> Section 3.1.4.4.3: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: The server sets the ftLastRefresh field of the structure with the value of the RefreshTime from the volume's entry in the ServerVolumeTable. But as specified in section 3.2.4.4.3, the client does not process this value.

<9> Section 3.1.5: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: This behavior is performed. If there are multiple instances of the server running, because there are multiple DCs in the domain, this behavior is only performed by one instance.

<10> Section 3.2.1: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: All local, compatible volumes are initialized, up to 26 volumes. If there are more than 26 compatible volumes, 26 are chosen arbitrarily (the first 26 compatible volumes returned by FindFirstVolume as described in [MSDN-FNDFSTVOL] and FindNextVolume as described in[MSDN-FNDNXTVOL]).

A volume is considered compatible if all of the following are true:

  • The volume is formatted with the NTFS file system.

  • The file system supports ObjectIDs.

    This is determined by using the GetVolumeInformation request, and checking in the lpFileSystemFlags parameter to GetVolumeInformation that the FILE_SUPPORTS_OBJECT_IDS flag is set. For more information on the GetVolumeInformation request, see [MSDN-GETVOLINFO].

  • The volume is nonremovable.

    This is determined by using the GetDriveType request, and checking that the return value is DRIVE_FIXED. For more information on the GetDriveType request, see [MSDN-GETDRIVETYPE].

<11> Section 3.2.1: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: The client maintains 10,000 entries in this list. When this list is its maximum size, and a new entry is to be added, the entry is added such that it replaces the oldest entry in the list.

<12> Section 3.2.1: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: A file is considered to be part of the VolumeFileTable if it has an ObjectID. For example, a file has an ObjectID if a FSCTL_CREATE_OR_GET_OBJECT_ID request ([MS-FSCC], section 2.3.1) is successfully processed for the file. This request is sent for a file if a Shell Link is created for it. For more information on Shell Links, see [MSDN-SHELLLINKS].

<13> Section 3.2.3: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: All local, compatible volumes are initialized, up to 26 volumes. If there are more than 26 compatible volumes, 26 are chosen arbitrarily (the first 26 compatible volumes returned by FindFirstVolume as described in [MSDN-FNDFSTVOL] and FindNextVolume as described in[MSDN-FNDNXTVOL]).

A volume is considered compatible if all of the following are true:

  • The volume is formatted with the NTFS file system.

  • The file system supports ObjectIDs.

    This is determined using the GetVolumeInformation request, and checking in the lpFileSystemFlags parameter to GetVolumeInformation that the FILE_SUPPORTS_OBJECT_IDS flag is set. For more information on the GetVolumeInformation request, see [MSDN-GETVOLINFO].

  • The volume is nonremovable.

    This is determined using the GetDriveType request, and checking that the return value is DRIVE_FIXED. For moreinformation on the GetDriveType request, see [MSDN-GETDRIVETYPE].

<14> Section 3.2.6.6: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: As new, compatible volumes become available on the local computer, they are added to the ClientVolumeTable.

<15> Section 3.2.6.6: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: The VolumeInformation information is physically stored on the volume. So if a volume is reformatted such that there is no data on the volume, there will be no VolumeInformation table associated with that volume.