Partager via

3.1.4.2 Receiving a MOVE_NOTIFICATION Message

  • Article

The MOVE_NOTIFICATION message is received by the server as part of a LnkSvrMessage request, as defined in section 3.1.4.1. The server uses the information in this message to update the FileTable that is used to process SEARCH requests (see section 3.1.4.6) with information about the new locations of files.

This message consists of a TRKSVR_CALL_MOVE_NOTIFICATION structure (described in section 2.2.12.1), which contains information for zero or more move notifications.

If the RequestMachine, as specified in section 3.1.4.1, is not the VolumeOwner of the VolumeID indicated in the pvolid field of the request, then the request MUST return with a return value of TRK_S_VOLUME_NOT_OWNED. If the VolumeID does not exist in the ServerVolumeTable, the request MUST return with a value of TRK_S_VOLUME_NOT_FOUND.

If the seq field is not equal to the VolumeSequenceNumber for the VolumeID in the ServerVolumeTable, then:

  • The message MUST return with a value of TRK_S_OUT_OF_SYNC.

  • The seq field of the message MUST be updated by the server to be the value of the VolumeSequenceNumber field of the ServerVolumeTable for this volume.

  • The server MUST NOT perform any of the following additional processing.

As stated earlier in this section, a single MOVE_NOTIFICATION message contains information for one or more files that have been moved. The fields of the TRKSVR_CALL_MOVE_NOTIFICATION structure for this message MUST be interpreted by the server as follows:

  • The pvolid field MUST be interpreted as the VolumeID that identifies the volume from which all files in this message were moved.

  • Each entry in the rgobjidCurrent array MUST be interpreted as the ObjectID of a file before it was moved. Therefore, as described in section 1.1, the file's PreviousFileLocation (the FileLocation before the move) is a composition of the preceding VolumeID and this ObjectID.

  • Each corresponding entry in the rgdroidBirth array MUST be interpreted as the moved file's FileID.

  • Each corresponding entry in the rgdroidNew array MUST be interpreted as the moved file's new FileLocation.

For example, if a MOVE_NOTIFICATION message contains two notifications, the information for the second notification is represented by the pvolid field, and by the second entry in each of the rgobjidCurrent, rgdroidBirth, and rgdroidNew arrays.

Each of these notifications MUST be processed by the server, in the order in which they appear in the array, as follows:

  • If the RecentTableUpdateCount has reached its maximum value, this notification and all remaining notifications MUST NOT be processed, and the server MUST return a failure return value to the client.

  • If the FileTable already contains an entry that maps the FileID to a FileLocation, and that FileLocation is the same value as the PreviousFileLocation specified in the notification, then the entry MUST be updated such that its FileLocation is the FileLocation specified in the notification. The RecentTableUpdateCount MUST also be incremented.

  • Otherwise, if the FileTable has already reached its maximum size (defined in the following bulleted list), this notification and all remaining notifications MUST NOT be processed.

  • Otherwise, a new entry MUST be added to the FileTable, with the PreviousFileLocation that was specified in the request stored in the PreviousFileLocation field, the new FileLocation from the request stored in the FileLocation field, and the FileID from the request stored in the FileID field. Also, the RecentTableUpdateCount MUST be incremented.

As stated earlier in this section, the FileTable has a maximum size. The maximum size of the FileTable MUST be calculated as follows:

  • For every entry in the ServerVolumeTable up to 5000 entries, add 200 times the number of entries to the value for the FileTable size limit.

  • For every entry in the ServerVolumeTable in addition to 5000 entries, add 100 times that number to the value for the FileTable size limit.

For example, if the ServerVolumeTable has 10 entries, the maximum FileTable size is 10*200, or 2000. If the ServerVolumeTable has 5010 entries, the maximum FileTable size is 5000*200 + 10*100, or 1,001,000.

If one or more notifications are not processed because the FileTable reaches its maximum size, the server MUST return a value of TRK_S_NOTIFICATION_QUOTA_EXCEEDED from the LnkSvrMessage request.

Note that this is a success code, so the server might still have processed some of the notifications in this request.

The server MUST increment the VolumeSequenceNumber for the VolumeID in the ServerVolumeTable once for each of the move notifications processed in this request. When the value of the VolumeSequenceNumber reaches its maximum positive value (2147483647), incrementing MUST result in its most negative value (2147483648). For example, if a MOVE_NOTIFICATION request has a seq field value of 10, a cNotifications field value of 3, and returns with a cProcessed field value of 2, the next MOVE_NOTIFICATION request for this VolumeID has a seq field value of 12.