Does the CreateDisposition flag of a client depend on Server's response ?

[Tom Talpey]

Aha - ok, if Windows-to-Windows is broken, it's in robocopy.
Interestingly, I can't repro this from my Win11 system to
a Samba server with streams_xattr loaded.

Yes, I'm aware it's the directory create that fails.

Maybe one other thing to test. What if you add the "X" copyflag,
which turns off copying streams? Perhaps your robocopy.exe will
ignore the filesystem stream attribute and use FILE_OPEN like usual.
It's purely an academic exercise though.

robocopy C:\Users\mittal\Downloads Y:\Shared\Folder1\Subfolder 
<file-name> /COPY:DATX /R:1 /W:10



On 2/5/2023 11:44 AM, varun mittal wrote:
> Hi Tom
> 
> I did test it with Windows share too and the behavior was the same.
> But please note, the FILE_OPEN_IF I am chasing is for the Directory
> and not the files.
> In my case, the source directory doesn't have any named data stream.
> The files in the source directory also didn't have any ADS. These files were
> generated locally.
> 
> On Sat, Feb 4, 2023 at 7:38 PM Tom Talpey <tom at talpey.com 
> <mailto:tom at talpey.com>> wrote:
> 
>     This is worth figuring out.
> 
>     Because it's a file in your Downloads folder, it was probably
>     created by a browser. This means it has an additional stream
>     which indicates it's from the internet. Defender and other
>     tools use the presence of that stream to throw the "Do you
>     really want to open this file?" dialogs.
> 
>     When you copy the file to a non-stream filesystem, that stream
>     is obviously lost, in which case robocopy is not going to do
>     anything special. But when copying to a filesystem that does,
>     it will take a different path, copying everything. Or maybe it's
>     the fact that it's in the Downloads folder, and robocopy is
>     being clever. Or just a bug in the Win10 robocopy you mentioned
>     you're using.
> 
>     Would you happen to have a Windows system with an NTFS share
>     that you could robocopy the same file to, and grab a trace?
> 
>     It would give us the breadcrumbs to figure out what's missing.
>     Maybe there's some other volume or filesystem attribute that's
>     missing, and confusing robocopy.
> 
>     Tom.
> 
>     On 2/4/2023 3:17 AM, varun mittal wrote:
>      > Nothing fancy, simple copy command:
>      > robocopy C:\Users\mittal\Downloads Y:\Shared\Folder1\Subfolder
>      > <file-name> /COPY:DAT /R:1 /W:10
>      >
>      > On Sat, Feb 4, 2023, 8:05 AM Tom Talpey <tom at talpey.com
>     <mailto:tom at talpey.com>
>      > <mailto:tom at talpey.com <mailto:tom at talpey.com>>> wrote:
>      >
>      >     On 2/3/2023 12:50 PM, Jeremy Allison via samba-technical wrote:
>      >      > On Fri, Feb 03, 2023 at 08:51:57PM +0530, varun mittal wrote:
>      >      >>   I was able to narrow it down to the "Named Streams" bit in
>      >      >>   "FileFSAttributeInformation" response.
>      >      >>   When this value is toggled from 0 to 1, as is advertised by
>      >      >>   `streams_xattr` VFS module, Robocopy
>      >      >>   switched from FILE_OPEN to FILE_OPEN_IF.
>      >      >>   Thanks
>      >      >
>      >      > Thanks for tracking that down. What strange behavior.
>      >      > I can't see why having a stream would make the open
>      >      > change to optionally creating the file, but it's good
>      >      > info to know. Thanks for posting the follow-up to
>      >      > the list !
>      >
>      >     It's not the presence af a stream, it's that the fileystem
>     supports
>      >     named streams. It's getting that from a
>     FileFsAttributeInformation
>      >     on the root directory.
>      >
>      >     Robocopy has a very broad range of OS- and FS-dependent behaviors
>      >     and optimizations. I bet there's some combination of its 1000-odd
>      >     commandline options that can change this.
>      >
>      >     Varun, what exact robocopy command are you seeing this from?
>      >
>      >     Tom.
>      >
>