Share via

7 Appendix B: Product Behavior

  • Article

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 XP operating system

  • Windows Server 2003 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

  • Windows 10 operating system 

  • Windows Server 2016 operating system

  • Windows Server operating system

  • Windows Server 2019 operating system

  • Windows Server 2022 operating system

  • Windows 11 operating system

  • Windows Server 2025 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 an expectation to keep information about the file by creating a Shell shortcut for it. The Shell shortcut is a file stored on M0 that holds the UNC, MachineID, FileLocation, and FileID for F"1.txt".

<2> Section 1.3: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: These calls are triggered when the user activates the Shell shortcut that was created to store information about the file "F1.txt". When the Shell shortcut is activated, it attempts to open the file. M1 returns an error indicating that the file does not exist, so the Shell shortcut implementation initiates the call to the DLT workstation on M1 to get the updated UNC. After storing the new FileLocation and UNC in the Shortcut file, the Shell shortcut implementation opens the destination file "F2.txt", and loads it into, for example, 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.

<3> Section 2.1: Windows 2000: The DLT Workstation server listens only on the "\\pipe\ntsvcs" endpoint, and it makes calls only to that endpoint.

Windows XP and Windows Server 2003: The server listens on both the "\\pipe\ntsvcs" and "\\pipe\trkwks" endpoint, and they make calls to "\\pipe\trkwks" first. If such a call results in a failure return value of 0xC0020017, which indicates that the pipe name was not found, these implementations make calls to the "\\pipe\ntsvcs" endpoint instead.

Otherwise, Windows: The server listens only on the "\\pipe\trkwks" endpoint.

<4> Section 3.1.1: In a configuration where a DLT Central Manager server is available, the VolumeID is generated by using that protocol. Otherwise, an arbitrary VolumeID is generated.

<5> Section 3.1.1: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: The CrossVolumeMoveFlag is stored as the low-order bit of the first byte of the CVolumeID, as specified in section 3.1.1.

<6> Section 3.1.1: Not all files on a volume have an ObjectID. Those files without an ObjectID are not considered part of this abstract data model.

<7> Section 3.1.3: Windows 2000: The DLT Workstation server listens only on the "\\pipe\ntsvcs" endpoint.

Windows XP and Windows Server 2003: The server also listens on the "\\pipe\trkwks" endpoint.

Otherwise, Windows : The server listens only on the "\\pipe\trkwks" endpoint.

<8> Section 3.1.4: Opnums reserved for local use apply to Windows as follows.

Opnum

Description

0-3

Not used by Windows.

4

Returns ERROR_NOT_IMPLEMENTED. It is never used.

5-8

Not used by Windows.

9

Only used locally by Windows, never remotely.

10-11

Not used by Windows.

<9> Section 3.1.4.1: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: This field is a set of flags, but it is unused by the client. Servers alter their behavior in response to these flags, which are summarized as follows:

  • 0x02: Prevents move notification information stored in the MoveTable from being used during a search request.

  • 0x10: Prevents the service from searching any volume except the volume that is specified by the VolumeID in the request.

  • 0x20: Prevents the search operation from giving preference to the volume specified by the VolumeID in the request, for the case where the requested file is located on multiple volumes. This flag also prevents the search operation from searching any machine other than the last known machine.

<10> Section 3.1.4.1: Windows 2000, Windows XP without any service packs, and Windows XP operating system Service Pack 1 (SP1) follow this behavior. In Windows XP operating system Service Pack 2 (SP2), Windows XP operating system Service Pack 3 (SP3), and Windows Server 2003, a failure value is returned if the path to be returned exceeds 130 characters. In Windows Vista, Windows 7, Windows 8, and Windows 8.1, if the path to be returned exceeds 259 characters, a success code is returned, but the returned ptszPath argument is truncated to return only the machine and share names, not the file path.

<11> Section 3.1.4.1: If there are multiple valid UNC paths, the path to be returned is chosen as follows:

  • A UNC path with read/write access privileges is preferred to a UNC path with only read access privileges.

  • If two paths have the same access privileges, a UNC path with greater coverage of the volume is preferred to a UNC path with less coverage. For example, a UNC path of C:\DOCUMENTS has more coverage than a path of C:\DOCUMENTS\LETTERS.

  • If two paths have the same access privileges and coverage, a visible path is preferred over a hidden path. A path is considered hidden if the share in the path ends in a '$' character, such as C$ or D$.

  • If, after the preceding checks, no preference can be made between two paths, one is chosen arbitrarily.

<12> Section 3.1.4.1: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: This situation occurs in a backup/restore sequence of operations. When a file is backed up, its ObjectID and FileID are stored with the backup data. When the file is restored:

  • If the file is being restored over an existing file, and the file already has an ObjectID set, it is left unmodified.

  • If another file on the volume to which the file is being restored already has the ObjectID, then no ObjectID is set on the restored file.

  • Otherwise, the ObjectID is restored onto the file, but the FileID is not. This is because of the ambiguity of a restore operation, which could be a true restore operation for a corrupted disk, or could be a copy operation.

<13> Section 3.1.6: If a file does not already have an ObjectID and FileID, one is created for it.

<14> Section 3.1.6: If a file does not already have an ObjectID value and a FileID value, this request returns an error result.

<15> Section 3.1.6.2: All versions of Windows listed in the supported products list in Appendix B: Product Behavior follow this recommendation except when the local and target machines are both running Windows Vista and later. On those versions, the request is not sent, and consequently this procedure is not followed.

<16> Section 3.1.6.2: If the local and remote machines are both running Windows 2000, Windows XP, or Windows Server 2003, then the [MS-SMB] protocol is used. Otherwise, the [MS-SMB2] protocol is used.

<17> Section 3.1.6.3: As noted in section 3.1.1 a file's moves are not tracked if it does not have an ObjectID and FileID. To determine whether the source file is to be tracked, all Windows implementations send an FSCTL_GET_OBJECT_ID request ([MS-FSCC] section 2.3.25) for the source file. If that request succeeds, and the BirthObjectId field of the FILE_OBJECTID_BUFFER structure ([MS-FSCC] section 2.1.3) in the response is not all zeros, then the file is tracked as described in this section.

<18> Section 3.1.6.3: All versions of Windows listed in the supported products list in Appendix B: Product Behavior follow this recommendation except when the local and target machines are both running Windows Vista and later. On those versions, this request is not sent, and consequently this procedure is not followed.

<19> Section 3.1.6.3: If the local and remote machines are both running Windows 2000, Windows XP, or Windows Server 2003, then the [MS-SMB] protocol is used. Otherwise, the [MS-SMB2] protocol is used.

<20> Section 3.1.6.4: As noted in section 3.1.1 a file's moves are not tracked if it does not have an ObjectID and FileID. To determine whether the source file is to be tracked, all Windows implementations send a FSCTL_GET_OBJECT_ID request for the source file. If that request succeeds, and the BirthObjectId field of the FILE_OBJECTID_BUFFER structure ([MS-FSCC] section 2.1.3) in the response is not all zeros, then the file is tracked as described in this section.

<21> Section 3.1.6.4: All versions of Windows listed in the supported products list in Appendix B: Product Behavior follow this behavior, except if the local machine is running Windows Vista and later the source machine is not running Windows Server 2008 and later. In these cases, the following steps under "If the source MachineID and target MachineID are the same" are followed. Note that in those steps, the FSCTL_LMR_SET_LINK_TRACKING_INFORMATION request fails, because the Fid of the target file represents a file on the target machine, and the request is being sent to the source machine.

<22> Section 3.1.6.4: If the local and remote machines are both running Windows 2000, Windows XP, or Windows Server 2003, then the [MS-SMB] protocol is used. Otherwise, the [MS-SMB2] protocol is used.

<23> Section 3.1.6.4: All versions of Windows listed in the supported products list in Appendix B: Product Behavior follow this recommendation except when either of the following is true:

  • The local and source machines are both running Windows Vista and later.

  • The local machine is running Windows Vista without any service packs and the source machine is running Windows Server 2008 and later.

In these cases, this request is not sent, and consequently the following step is not followed.

<24> Section 3.1.6.4: If the local and remote machines are both running Windows 2000, Windows XP, or Windows Server 2003, then the [MS-SMB] protocol is used. Otherwise, the [MS-SMB2] protocol is used.

<25> Section 3.2.3: Windows 2000: The DLT Workstation client sends only on the "\\pipe\ntsvcs" endpoint

Otherwise, Windows based clients initially sends on the "\\pipe\trkwks" endpoint.

<26> Section 3.2.4.1: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: After receiving this error from a DLT Workstation server, a new SEARCH call is initiated to the DLT Central Manager, as specified in [MS-DLTM] section 3.2.6.3. If this SEARCH call fails with a TRK_E_NOT_FOUND error, the client uses the VolumeID component of the FileLocation returned with referral in a FIND_VOLUME request to the DLT Central Manager, as specified in [MS-DLTM] section 3.2.6.4. If both of these calls to the DLT Central Manager fail, the processing specified earlier in this section for TRK_E_REFERRAL is also followed. If this SEARCH call succeeds, the same processing is followed, only using the MachineID and FileLocation values returned from the DLT Central Manager call. If the SEARCH call returns a TRK_E_NOT_FOUND error, but the subsequent FIND_VOLUME succeeds, the same processing is followed, only using the FileLocation from the referral and the MachineID returned from the FIND_VOLUME request. In each of these cases, if another TRK_E_REFERRAL return value is subsequently received, the preceding processing specified for TRK_E_REFERRAL is followed; no new call is made to the DLT Central Manager.

<27> Section 3.2.4.1: All versions of Windows listed in the supported products list in Appendix B: Product Behavior: This typically causes the user to be prompted with a dialog box. The dialog box states that the file could not be found, but a new file was found that might be correct. The user is prompted either to use that file or to abort the action.