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

[Tom Talpey]

Sorry, I missed that DCOPY:X fixes it. Weird though, since robocopy
isn't copying the directory in your example, just the file.

Ok, definitely a robocopy thing, not a protocol one. :) Thanks!

Tom.

On 2/6/2023 2:19 PM, varun mittal wrote:
> I observe the same behavior with my Win10 client and Samba server with 
> streams_xattr.
> 
> The /COPY:DATX didn't change the behavior for the directory, but 
> /DCOPY:X does as I had
> mentioned in my earlier comments.
> And not sure why, but only /DCOPY:X does, if I specify any other flag 
> like /DCOPY:DAX, it doesn't :)
> 
> 
> On Mon, Feb 6, 2023 at 11:24 PM Tom Talpey <tom at talpey.com 
> <mailto:tom at talpey.com>> wrote:
> 
>     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>
>      > <mailto: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>>
>      >      > <mailto: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.
>      >      >
>      >
>