Matthieu, While sending the CMD_REMOTE_CO command, the upstream should always include the MD5 hash which would allow the downstream to determine if it has already got this change order, maybe from some other partner. From the examples you provided, it appears that it is related to the behavior of CS_SEND_STAGE command. This command is sent by the downstream. For this command, the MD5 hash is included only if the downstream has an existing file of the name included in the change order sent from the upstream. It obviously cannot compute a MD5 hash if it has no such file and therefore sets it to NULL. This is the reason why you saw this behavior.
Please let me know if you have more questions. Thanks! Hongwei -----Original Message----- From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Matthieu Patou Sent: Thursday, November 17, 2011 3:48 PM To: cifs-proto...@samba.org; p...@tridgell.net; Interoperability Documentation Help Subject: [cifs-protocol] data checksum value in FRS Hello Dochelp, Paragraph 2.2.3.7DATA_EXTENSION_CHECKSUM of MS-FRS1 indiciate about the data checksum: Data: MUST be a 128-bit MD5 digest of staging file and attributes, as specified in [RFC1321]. See section 2.2.3.10 for how the MD5 digest is constructed on a staging file and attributes. Section 2.2.3.10 didn't bring much more information, but it seems while looking at a replication (initial + regular) between 2 DCs that the checksum attribute is sometime omitted (it's 16 null bytes). Like in packet 3286 in the attached trace. At the opposite in packet 5300 we have a non null checksum, can you explain in which case the checksum can or must be null ? The trace is attached to this email. Thanks. Matthieu. -- Matthieu Patou Samba Team http://samba.org _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
