[EXTERNAL] Re: Windows 10 client opens a folder as a file and asks for SMB2 GetInfo SMB2_FILE_STREAM_INFO

ronnie sahlberg ronniesahlberg at gmail.com
Thu May 7 21:49:07 UTC 2020


On Fri, May 8, 2020 at 7:34 AM Ashok Ramakrishnan via samba-technical
<samba-technical at lists.samba.org> wrote:
>
> Thanks Jeremy, Roland and Ralph for your responses. Just wanted to loop back and update you all on the progress we made. It turned out to be that the path length of the next file the client was going to open was > 256 characters, and the client (windows 10 -> file explorer -> right click on folder -> properties) silently drops a path component when this happens... It wasn't obvious to me since the client did not truncate the file at the end, instead decided to drop a component from the path. In my attempt to model the client behavior, I recreated the directory structure (by extracting the path and filenames from the pcap) and was able to reproduce it myself.
>

Wait. What?
You are saying that if the full path exceeds 256 characters then the
client tries to recover from this by just discarding random path
components until it is <256 bytes  and tries that instead?

>
>
> -----Original Message-----
> From: Jeremy Allison [mailto:jra at samba.org]
> Sent: Friday, May 1, 2020 3:01 PM
> To: Ashok Ramakrishnan <aramakrishnan at nasuni.com>
> Cc: samba-technical at lists.samba.org
> Subject: Re: [EXTERNAL] Re: Windows 10 client opens a folder as a file and asks for SMB2 GetInfo SMB2_FILE_STREAM_INFO
>
> On Fri, May 01, 2020 at 06:30:48PM +0000, Ashok Ramakrishnan wrote:
> > Thanks Jeremy for the tip. Our customer is able to reproduce this readily. So, I can try potential patches. One interesting observation I have since you pointed out the Reparse Point bit... The previous getinfo command was file network open info. And we (samba) responding with this for the folder...
> >
> > SMB2_FILE_NETWORK_OPEN_INFO
> >     Created: Nov  6, 2015 20:22:26.658586900 Eastern Standard Time
> >     Last Access: Nov  6, 2015 20:22:26.659295100 Eastern Standard Time
> >     Last Write: Nov  6, 2015 20:22:36.530589900 Eastern Standard Time
> >     Change: Nov  6, 2015 20:22:36.530589900 Eastern Standard Time
> >     Allocation Size: 0
> >     End Of File: 0
> >     File Attributes: 0x00000010
> >         .... .... .... .... .... .... .... ...0 = Read Only: NOT read only
> >         .... .... .... .... .... .... .... ..0. = Hidden: NOT hidden
> >         .... .... .... .... .... .... .... .0.. = System: NOT a system file/dir
> >         .... .... .... .... .... .... .... 0... = Volume ID: NOT a volume ID
> >         .... .... .... .... .... .... ...1 .... = Directory: DIRECTORY
> >         .... .... .... .... .... .... ..0. .... = Archive: Has NOT been modified since last archive
> >         .... .... .... .... .... .... .0.. .... = Device: NOT a device
> >         .... .... .... .... .... .... 0... .... = Normal: Has some attribute set
> >         .... .... .... .... .... ...0 .... .... = Temporary: NOT a temporary file
> >         .... .... .... .... .... ..0. .... .... = Sparse: NOT a sparse file
> >         .... .... .... .... .... .0.. .... .... = Reparse Point: Does NOT have an associated reparse point
> >         .... .... .... .... .... 0... .... .... = Compressed: Uncompressed
> >         .... .... .... .... ...0 .... .... .... = Offline: Online
> >         .... .... .... .... ..0. .... .... .... = Content Indexed: NOT content indexed
> >         .... .... .... .... .0.. .... .... .... = Encrypted: This is NOT an encrypted file
> >     Reserved: 00000000
> >
> > We specifically said that it IS a Directory and NOT a reparse point. But the client still decided to send us a 0x00200020 in the subsequent open of the file. I can play with the response and see if I can get the client to behave differently...
>
> Yeah, I just checked with test code against Windows10 and the server just ignores a request to open a reparse point if the object is just a regular file/directory.
>
> So this may be a red herring. Would be interesting to see a trace of this application at the same point against a Windows server.
> This e-mail message and all attachments transmitted with it may contain privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message, all attachments and all copies and backups thereof.
>



More information about the samba-technical mailing list