[cifs-protocol] 119030519730578 server response for oversized alternate data streams
edgaro at microsoft.com
Tue Mar 5 20:24:59 UTC 2019
Can you please share some network captures (e.g. .cap traces ) of your test cases?
I will investigate this and follow-up.
From: Sreekanth Nadendla <srenaden at microsoft.com>
Sent: Tuesday, March 5, 2019 9:38 AM
To: Björn JACKE <bj at SerNet.DE>; cifs-protocol at lists.samba.org
Cc: MSSolve Case Email <casemail at microsoft.com>
Subject: 119030519730578 server response for oversized alternate data streams
Dochelp in Bcc
Casemail in Cc
Hello Björn JACKE,
Thank you for your inquiry. We have created an incident for investigating this issue. One of the Open specifications team member will contact you shortly.
Microsoft Windows Open Specifications
From: Björn JACKE <bj at SerNet.DE>
Sent: Tuesday, March 5, 2019 4:03 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>; cifs-protocol at lists.samba.org
Subject: server response for oversized alternate data streams
I have a question regarding the correct server response and the Windows client expectations on the server response when writing an alternate data stream
There is the well known case of VFAT volumes, where a client trying to write an ADS over the wire gets back STATUS_OBJECT_NAME_COLLISION because ADS are not supported there. Current Windows 10 explorer clients handle that situation gracefully and ask the user is the file(s) should be copied without its properties. So copying the main file is still possible.
There is also the case with filesystems which support only a limited size for ADS, ReFS is a native Windows filesystems which also has as 128k limit. Trying to write a ADS larger that that max supported size results in a STATUS_FILE_SYSTEM_LIMITATION response over the wire. Current Windows 10 explorer clients do NOT handle this gracefully and only allow to skip copying that file entirely.
Is there a specific reason for the different server responses here and a reason why the one case is handled gracefully and the other one is handled not so gracefully by the client?
The main question finally is - in order to achieve graceful client behaviour by sending a different server resonse than STATUS_FILE_SYSTEM_LIMITATION: Would it be allowed to return STATUS_OBJECT_NAME_COLLISION when an overlarge ADS is being written but when ADS are supported otherwise? Or are Windows clients making larger assumptions about the server behaviour in case STATUS_OBJECT_NAME_COLLISION is being returned for a specific ADS only?
Thanks in advance!
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%7Cd98450f9ff0a47328fb908d6a1809114%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873970903170531&sdata=z2nQvLt00PYxOGwNzNJpAuT6qCt11krRMSiBJzHOXfc%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%7Cd98450f9ff0a47328fb908d6a1809114%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873970903170531&sdata=f7JxwCD04Cqvz0yXRkUv3rBPr56LbtGIm4wtWUjNC20%3D&reserved=0
More information about the cifs-protocol