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

Sreekanth Nadendla srenaden at microsoft.com
Tue Mar 5 15:38:05 UTC 2019


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.

Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications

-----Original Message-----
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

Hello dochelp,

I have a question regarding the correct server response and the Windows client expectations on the server response when writing an alternate data stream
(ADS) fail.

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!
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%7Csrenaden%40microsoft.com%7Cabfdb6b99fae41e814d608d6a14a19d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873736972804955&sdata=BCty8Tg5yrpPr3YA5b52GlRShhMmuFgjrJ3Y5ExQ5Do%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%7Csrenaden%40microsoft.com%7Cabfdb6b99fae41e814d608d6a14a19d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873736972804955&sdata=1BRWtU2KdW5qk4EzF7D%2FRrwXrAlxpJdWXtoUmGrTJ%2Bo%3D&reserved=0



More information about the cifs-protocol mailing list