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

[Björn JACKE]

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://www.sernet.de

Samba eXPerience 2019, Hotel Freizeit In
sponsored by Google, Microsoft & Red Hat
June, 4th - 6th 2019, http://sambaXP.org