[cifs-protocol] 119030519730578 server response for oversized alternate data streams

Edgar Olougouna edgaro at microsoft.com
Thu Mar 14 03:56:25 UTC 2019


Björn,
Since we do not have control over the whole client application ecosystem, we cannot predict what will happen if one error is returned instead of another. For Windows, this could be misleading. Based on the specification of what Windows protocol implementation does, it is advised that third-party implementers follow the normative rules to achieve maximum interoperability. 
The user experience related to the error is often application driven. The protocol will generally convey that an error is returned to the application, or it will specify that the protocol prescribes a retry if it deems necessary for the protocol sequence. Remember that an application retry - a lot of times - have less to do with the protocol retry.
It appears in this test case against FAT file system, it will trigger an application-level "Yes | Skip | Cancel" dialog due to the fact that the error conveys property loss if the file were copied. This gives the opportunity for the user to know that if they copy the file, they will lose content.
For the ReFS file system, it triggers an application-level "Retry | Skip | Cancel" dialog because there is not virtually a way for the copy to succeed as such because the destination file system has limitation. In my opinion, here, I think it should not have had a "Retry" in the dialog.
Other non-Windows client applications may act differently on the protocol errors they receive.
It is advised to follow the specification as much as applicable to a given protocol scenario, to enable a greater interoperability coverage between implementations.

With that, let me give some perspective on the following requirements terms (MUST, SHOULD, MAY) that could help you in your analysis and design decision.

In general, our open specifications "References" section has this statement: 
	MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.

Normative statements have requirement statements and are accompanied with various Windows product behavior notes <WBN> as they reflect our implementation.
MUST: This is a hard requirement. Windows always does it but it could be version-specific with a WBN. If an implementation doesn't do the same this usually break the protocol sequence and could substantially impact interop.
SHOULD: This an optional requirement. It usually has a WBN. Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies Windows behavior in accordance with the SHOULD or SHOULD NOT prescription. 
MAY: Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription. The MAY means Windows almost never does it. If it does, there would be a WBN which states how Windows diverts from that statement.

Thanks,
Edgar

-----Original Message-----
From: Edgar Olougouna 
Sent: Tuesday, March 12, 2019 4:30 PM
To: Björn JACKE <bj at SerNet.DE>
Cc: cifs-protocol at lists.samba.org; MSSolve Case Email <casemail at microsoft.com>
Subject: RE: 119030519730578 server response for oversized alternate data streams

Björn, 
As documented in MS-FSA (see reference), only NTFS and ReFS support stream name types. 
	See MS-FSA <43> Section 2.1.5.1: . . .
	Other Windows file systems do not recognize any stream type names. 

Regarding the graceful error handling on the client, one aspect is that FAT systems do not support more than one data stream, and the error generic the server returns when it doesn't support a stream type is STATUS_OBJECT_NAME_INVALID. ReFS is different, as it does support ADS, but has a limit which reports STATUS_FILE_SYSTEM_LIMITATION. I think the two error codes convey two different things. I will try to see whether I can provide further comment on this and follow-up.

I will open a document bug on MS-FSA and that we update the 128K limitation for ReFS ADS with error STATUS_FILE_SYSTEM_LIMITATION.

MS-FSA
2.1.5.1	Server Requests an Open of a File
§	If StreamTypeNameToOpen is non-empty and StreamTypeNameToOpen is not equal to one of the stream type names recognized by the object store<43> (using case-insensitive string comparisons), the operation MUST be failed with STATUS_OBJECT_NAME_INVALID.
<43> Section 2.1.5.1: NTFS and ReFS recognize the following stream type names:
§	"$STANDARD_INFORMATION"
§	"$ATTRIBUTE_LIST"
§	"$FILE_NAME"
§	"$OBJECT_ID"
§	"$SECURITY_DESCRIPTOR"
§	"$VOLUME_NAME"
§	"$VOLUME_INFORMATION"
§	"$DATA"
§	"$INDEX_ROOT"
§	"$INDEX_ALLOCATION"
§	"$BITMAP"
§	"$REPARSE_POINT"
§	"$EA_INFORMATION"
§	"$EA"
§	"$LOGGED_UTILITY_STREAM"
Other Windows file systems do not recognize any stream type names.

Thanks,
Edgar 


-----Original Message-----
From: Edgar Olougouna 
Sent: Tuesday, March 5, 2019 4:01 PM
To: Björn JACKE <bj at SerNet.DE>
Cc: cifs-protocol at lists.samba.org; MSSolve Case Email <casemail at microsoft.com>
Subject: RE: 119030519730578 server response for oversized alternate data streams

Thanks Björn, I will take a look and get back to you. 
Edgar 

-----Original Message-----
From: Björn JACKE <bj at SerNet.DE> 
Sent: Tuesday, March 5, 2019 3:49 PM
To: Edgar Olougouna <edgaro at microsoft.com>
Cc: cifs-protocol at lists.samba.org; MSSolve Case Email <casemail at microsoft.com>
Subject: Re: 119030519730578 server response for oversized alternate data streams

Hello Edgar,

On 2019-03-05 at 20:24 +0000 Edgar Olougouna sent off:
> Can you please share some network captures (e.g. .cap traces ) of your test cases? 
> I will investigate this and follow-up.

thanks for your answer, attached there are 2 captures of a current Windows 10 client (explorer.exe) copying a file test.txt with a ~400kb ADS "mystream" in it onto a 2012R2 server.

refs-sniff-packet-487.pcap.gz:
In this capture the share is a ReFS (128k sized ADS supported) volume, see packet 487 ff.

vfat-sniff-packet-147.pcap.gz:
In this capture the share is a vfat volume with no ADS support, see packet 147 ff.

There are also the screenshots of the dialogues the Windows 10 client shows when the ADS writes fails for both cases.

Thank you!
Björn
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: 0551-370000-0, mail: kontakt at sernet.de
Gesch.F.: Dr. Johannes Loxen & Reinhild Jung AG Göttingen: HR-B 2816 - https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.sernet.de&data=02%7C01%7Cedgaro%40microsoft.com%7C38514d342a8d4073590c08d6a1b4580e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636874193466020595&sdata=GIVEvFxHvqwTd%2BXvtSjmpBKPfk9Px2SbfsCOTLkn6ik%3D&reserved=0

Samba eXPerience 2019, Hotel Freizeit In sponsored by Google, Microsoft & Red Hat June, 4th - 6th 2019, https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2FsambaXP.org&data=02%7C01%7Cedgaro%40microsoft.com%7C38514d342a8d4073590c08d6a1b4580e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636874193466020595&sdata=WaCKgTPFKVbKLRddYFRPkwZZzclnFPhVhksKMqcT0%2Fk%3D&reserved=0



More information about the cifs-protocol mailing list