Share via

2.2.2.2.1.1 Handling the Symbolic Link Error Response

  • Article

If a symbolic link error response is received, it MUST be processed by the calling application as follows:

  1. The unparsed portion of the original path name that is located at the end of the path-name string MUST be extracted.

    The size, in bytes, of the unparsed portion is specified in the UnparsedPathLength field. The byte count MUST be used from the end of the path-name string and walked backward to find the starting location of the unparsed bytes.

  2. If the SYMLINK_FLAG_RELATIVE flag is not set in the Flags field of the symbolic link error response, the unparsed portion of the file name MUST be appended to the substitute name to create the new target path name.

  3. If the SYMLINK_FLAG_RELATIVE flag is set in the Flags field of the symbolic link error response, the symbolic link name MUST be identified by backing up one path name element from the unparsed portion of the path name. The symbolic link MUST be replaced with the substitute name to create the new target path name.

The following clarifies handling of the symbolic link error response:

  • An absolute symbolic link located on the server links "\\MachX\ShareY\Public\ProtocolDocs" to "\??\D:\DonHall\MiscDocuments\PDocs".

    1. The original open request is for "\\MachX\ShareY\Public\ProtocolDocs\DailyDocs\[MS-SMB].doc".

    2. The server returns a symbolic link error response with the following data:

      • UnparsedPathLength field value of 0x2E

      • PathBuffer containing the Unicode string substitute name and print name "\??\D:\DonHall\MiscDocuments\PDocsD:\DonHall\MiscDocuments\PDocs"

      • SubstituteNameoffset 0x00

      • SubstituteNamelength 0x44

        The unparsed portion of the path name will be "\DailyDocs\[MS-SMB].doc". Appending the substitute name with the unparsed portion of the file name gives the new target path name of "\??\D:\DonHall\MiscDocuments\PDocs\DailyDocs\[MS-SMB].doc".

  • A relative symbolic link located on the server links "\\MachX\ShareY\Public\ProtocolDocs" to "..\DonHall\Documents\PDocs".

    1. The original open request is for "\\MachX\ShareY\Public\ProtocolDocs\DailyDocs\[MS-SMB].doc".

    2. The server returns a symbolic link error response with the following data:

      • UnparsedPathLength field value of 0x2E

      • PathBuffer containing the Unicode string substitute name and print name "..\DonHall\Documents\PDocs..\DonHall\Documents\PDocs"

      • SubstituteNameoffset 0x00

      • SubstituteNamelength 0x34

        The symbolic link name in this case is "ProtocolDocs".

        Replacing the symbolic link name "ProtocolDocs" in the original open request (path name "\\MachX\ShareY\Public\ProtocolDocs\DailyDocs\[MS-SMB].doc") with the substitute name "..\DonHall\Documents\PDocs" gives the new target path name "\\MachX\ShareY\Public\..\DonHall\Documents\PDocs\DailyDocs\[MS-SMB].doc". Because "." and ".." are not permitted as components of a path name to be sent over the wire, before reissuing the SMB2 CREATE request the client MUST first eliminate the ".." by normalizing the new target path name to "\\MachX\ShareY\DonHall\Documents\PDocs\DailyDocs\[MS-SMB].doc".