3.2.5.5 DeleteNotificationTimer Expiration

When the DeleteNotificationTimer expires, if there are entries in the PendingDeleteNotificationList, the client MUST send the server notifications of those deleted files. See section 3.2.6.2 for more information about the PendingDeleteNotificationList. This MUST be sent to the server in a DELETE_NOTIFY message, which is part of a LnkSvrMessage request, as defined in section 3.1.4.1. In this request, the MessageType of the TRKSVR_MESSAGE_UNION parameter (see section 2.2.12) MUST be set to DELETE_NOTIFY, and the Priority field MUST be set to 5.

If, at the time the client is to send the notification, it has multiple notifications to send, then the client MUST send a batch of as many notifications as possible, up to 32 notifications, in a single message (see section 2.2.12.4 for a description of the TRKSVR_CALL_DELETE structure). As described in section 3.2.4.4, if there are more than 32 entries in the PendingDeleteNotificationList, the client attempts to send repeated messages, so that a notification for each entry in the list is sent to the server.

In each DELETE_NOTIFY message, the client MUST specify the fields in the TRKSVR_CALL_DELETE structure used in this request as follows:

adroidBirth: A list of up to 32 FileIDs from the PendingDeleteNotificationList for files that have been deleted.

pVolumes: Reserved; this value MUST be set to a NULL pointer.

See section 3.1.4.5 for information on the server processing of this message. See section 3.2.4.4 for information on the client's completion of this message.