Failed to get file list State is STATUS_NO_MORE_FILES

[yika-aixi]

The example code I refer to: https://github.com/TalAloni/SMBLibrary/blob/master/ClientExamples.md#connect-to-share-and-list-files-and-directories---smb2

System Ver: Windows10

No Enable: SMB 1.0

Shared Folder File Count: 6

[TalAloni]

STATUS_NO_MORE_FILES means success - it's not an error.

[yika-aixi]

STATUS_NO_MORE_FILES means success - it's not an error.

Oh, okay, thanks

[guyharris]

STATUS_NO_MORE_FILES means success - it's not an error.

To quote a comment I made elsewhere (an Illumos issue and a Wireshark issue) about this:

Where in [MS-SMB2] is it stated that only Status values with STATUS_SEVERITY_ERROR in the upper 2 bits indicate an error?

In 3.2.5.15 Receiving an SMB2 QUERY_DIRECTORY Response it says:

If the Status field of the SMB2 header of the response indicates an error, the client MUST return the received status code to the calling application.

If the Status field of the SMB2 header of the response indicates success, the client MUST copy the received information in the SMB2 QUERY_DIRECTORY Response following the SMB2 header that is described by the OutputBufferOffset and OutputBufferLength into the buffer that is provided by the calling application. The client MUST return success and the OutputBufferLength to the application.

If the Status field can indicate anything other than an error or success, they don't indicate what to do. Perhaps this is a failure on their part (unfortunately, I can't find a GitHub repository for the open specifications in which to file an issue), rather than "error" and "success" being the only two possibilities. They don't indicate what "error" means - Status != STATUS_SUCCESS, (Status & 0xC0000000) == 0xC0000000, or something else, nor do they indicate what "success" means - Status == STATUS_SUCCESS, (Status & 0xC0000000) != 0xC0000000, or something ese.

3.3.4.4 Sending an Error Response says "An error code other than one of the following indicates a failure:" and lists, after that:

• STATUS_MORE_PROCESSING_REQUIRED in an SMB2 SESSION_SETUP Response specified in section 2.2.6.
• STATUS_BUFFER_OVERFLOW in an SMB2 QUERY_INFO Response specified in section 2.2.38.
• STATUS_BUFFER_OVERFLOW in a FSCTL_PIPE_TRANSCEIVE, FSCTL_PIPE_PEEK or FSCTL_DFS_GET_REFERRALS Response specified in section 2.2.32.<227>
• STATUS_BUFFER_OVERFLOW in an SMB2 READ Response on a named pipe specified in section 2.2.20.
• STATUS_INVALID_PARAMETER in an FSCTL_SRV_COPYCHUNK or FSCTL_SRV_COPYCHUNK_WRITE response, when returning an SRV_COPYCHUNK_RESPONSE as described in section 3.3.5.15.6.2.
• STATUS_NOTIFY_ENUM_DIR in an SMB2 CHANGE_NOTIFY Response specified in section 2.2.36.

In particular, it does not list STATUS_NO_MORE_FILES or list an SMB2 QUERY_DIRECTORY Response.

First, we do have sample from windows response, with STATUS_NO_MORE_FILES, they only do set StructureSize field (to have mandatory value 9) and the rest is zeroes.

That's insistinguishable from what 2.2.2 SMB2 ERROR Response says is an ERROR response with:

• StructureSize 9;
• ErrorContextCount 0;
• Reserved 0;
• ByteCount 0;
• one zero byte of ErrorData;

so the response from Windows could well be an ERROR response.

BTW, FindNextFileW() is documented as failing with GetLastError() returning ERROR_NO_MORE_FILES if there are no more files, so the Windows SMB2 kernel client probably hands STATUS_NO_MORE_FILES up to userland in that case.