I reviewed your Server 2003 trace and verified that it does return 0x000003e5 (#define ERROR_IO_PENDING 997L). I will add this to the request for a behavior note.
Bryan From: Bryan Burgin Sent: Wednesday, September 29, 2010 3:55 PM To: '[email protected]'; Hongwei Sun Cc: MSSolve Case Email; [email protected]; Nick Meier; [email protected] Subject: RE: [REG:110092975377470] "Issue 2" (was "Summary of [MS-BKRP] 3.1.4.1.4 BACKUPKEY_RESTORE_GUID issues") [Merging threads] [Adding [email protected]<mailto:[email protected]>; Nick Meier [email protected]<mailto:[email protected]>] Matthieu, Regarding this issue on a separate thread, you added: "Bryan do you remember with which server do we have this ? because today with a w2k8 server I keep receiving WERR_IO_PENDING (0x000003E5) It seems to be w2k8r2 (for ERROR_INVALID_DATA). In fact it seems that we have IO_PENDING up to w2k8 included and then INVALID_DATA." We were using Server 2008 R2. Can you get a TT Trace with Server 2008 SP2 that shows WERR_IO_PENDING (0x000003E5) and I'll add that as a Windows behavior after researching the issue? As an implementer of the protocol, you should return ERROR_FILE_NOT_FOUND (2), as is recommended in the specification: [MS-BKRP] 3.1.4.1.4 Step 1: "Retrieve the ClientWrap key pair corresponding to the GUID specified by the guidKey field. If the key pair cannot be retrieved, the server MUST return an appropriate nonzero error code. The error code returned SHOULD be equal to ERROR_FILE_NOT_FOUND (0x2)." Bryan From: Bryan Burgin Sent: Wednesday, September 29, 2010 3:36 PM To: '[email protected]'; Hongwei Sun Cc: MSSolve Case Email Subject: [REG:110092975377470] "Issue 2" (was "Summary of [MS-BKRP] 3.1.4.1.4 BACKUPKEY_RESTORE_GUID issues") Matthieu, Regarding "Issue 2" (see mail below), I was able to verify that Server 2008 R2 does return ERROR_INVALID_DATA 0xd (14) in this scenario instead of the recommended ERROR_FILE_NOT_FOUND (0x2)." I filed a request with the product group to document that Server 2008 R2. The function that actually discovers the error properly returns STATUS_OBJECT_NAME_NOT_FOUND ((NTSTATUS)0xC0000034L) to its immediate caller, but does not call SetLastError(). The failure rolls back to previous callers as a Boolean fail/succeed instead of passing back the NTSTATUS code. A middle-level function knows that there was a failure (based on the Boolean that was passed back) and calls GetLastError() to determine its cause. Since the Last Error was never set, that comes back as zero (STATUS_SUCCESS). Since the middle-level function doesn't have an exact cause, it falls back to returning ERROR_INVALID_DATA (0xd). STATUS_OBJECT_NAME_NOT_FOUND ((NTSTATUS) 0xC0000034L), which would map to the Win32 error ERROR_FILE_NOT_FOUND (0x2), never gets communicated. Our repro was with Server 2008 R2. I suspect that this is the same across all the server versions. I recommended the behavior note: [MS-BKRP] 3.1.4.1.4 Step 1: "Retrieve the ClientWrap key pair corresponding to the GUID specified by the guidKey field. If the key pair cannot be retrieved, the server MUST return an appropriate nonzero error code. The error code returned SHOULD be equal to ERROR_FILE_NOT_FOUND (0x2). <nn>" "<nn> Windows Server 2008 R2 (and others) return ERROR_INVALID_DATA (0x0000000D)." If accepted, it will show up in a future update to MS-BKRP. Bryan From: Bryan Burgin Sent: Tuesday, September 28, 2010 11:35 AM To: '[email protected]'; Hongwei Sun Subject: Summary of [MS-BKRP] 3.1.4.1.4 BACKUPKEY_RESTORE_GUID issues Matthieu, [...] ISSUE TWO =========== x64 08R2 TTTrace at C:\CustomerFiles\Samba_backupkey\lsass03.run Issue: BACKUPKEY_RESTORE_GUID step #1: "Retrieve the ClientWrap key pair corresponding to the GUID specified by the guidKey field. If the key pair cannot be retrieved, the server MUST return an appropriate nonzero error code. The error code returned SHOULD be equal to ERROR_FILE_NOT_FOUND (0x2)." Expecting ERROR_FILE_NOT_FOUND 0x2 (2) Receiving ERROR_INVALID_DATA 0xd (14)
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
