SMB_COM_READ_ANDX MaxCount != filesize

[Nadav Danieli]

Observing windows behavior, I've noticed that for operation like copy that has no oplock w2k sends one read_andx for an offset beyond EOF (in fact two reads try to read beyond EOF, but one overlapped some data in the file.)
Also, every copy operation send open_andx requests twice, one for the read and the other ithink is a "stat" open, which has to break the first's oplock if granted. With kernel oplocks = yes, this always break the oplock to none.
My tests were done with large files though.

	-----Original Message----- 
	From: Sailaja Josyula [mailto:sailaja at us.ibm.com] 
	Sent: Thu 3/17/2005 4:01 AM 
	To: Christopher R. Hertel 
	Cc: samba-technical at lists.samba.org 
	Subject: Re: SMB_COM_READ_ANDX MaxCount != filesize
	
	

	Thanks for your reply Chris.
	
	I need to clarify some aspects.
	
	SMB_COM_READ_ANDX is asking for MaxCount much greater than the filesize.
	
	If say I have a file of size 68 bytes.  I am seeing the following
	sequence:
	
	  NT_CREATE_ANDX response End_Of_File set to 68
	
	  follows the first SMB_COM_READ_ANDX with offset = 0; MaxCount = 512
	  second SMB_COM_READ_ANDX with offset = 68; MaxCount = 444
	  and so on ... some 10 more SMB_COM_READ_ANDX commands follow.
	
	
	On a regular VFS (Using Windows SMB) the same file is opened with the
	following sequence:
	
	NT_CREATE_ANDX response End_Of_File set to 68
	follows the first SMB_COM_READ_ANDX with offset = 0; MaxCount = 68
	
	
	Is this to do with the negotiated protocol?  I am not sure what the
	Application uses to get the MaxCount for SMB_COM_READ_ANDX.
	
	Thanks
	
	Sailaja Josyula
	Websphere Odyssey (On Demand Client) Development
	IBM Software Group
	Phone: 914-784-5472 Tie Line: 863-5472 Fax: 914-784-3833
	sailaja at us.ibm.com
	
	
	
	
	"Christopher R. Hertel" <crh at ubiqx.mn.org>
	03/16/2005 03:12 PM
	
	        To:     Sailaja Josyula/Hawthorne/IBM at IBMUS
	        cc:     samba-technical at lists.samba.org
	        Subject:        Re: SMB_COM_READ_ANDX MaxCount != filesize
	
	
	Hmmm...
	
	So if I understand this correctly, the clients (Windows clients, I
	presume) are never asking for as many bytes as they could actually read.
	Is the difference consistent?  That is, for small files is MaxCount
	always, say, 8 bytes less than you'd expect?
	
	My guess is that some parameter in the initial negotiation is off by a
	fixed number of bytes.  If that guess is correct, it's probably a result
	of not counting soe field that un-obviously needs to be counted.  SMB
	field offsets and such are sometimes a little weird that way.
	
	Chris -)----
	
	On Wed, Mar 16, 2005 at 02:49:35PM -0500, Sailaja Josyula wrote:
	> Hi,
	>
	> I have written my own SMBserver to run as a VFS.  I have question
	> regarding SMB_COM_READ_ANDX command.
	>
	> The MaxCount parameter in the command SMB_COM_READ_ANDX is never set to
	> the filesize. Even though I am setting
	> the End_Of_File parameter correctly in the response to NT_CREATE_ANDX
	> command.
	>
	> In the windows SMB I see that the SMB_COM_READ_ANDX requests come with
	the
	> Count set to the Filesize specified
	> in the NT_CREATE_ANDX command.  The MaxCount field not being set
	correctly
	> is causing multiple SMB_COM_READ_ANDX
	> commands to be triggered with different offset and Count values, even if
	
	> the filesize is as small as 8 bytes.
	>
	> Is there something I am missing or not setting prior to the
	> SMB_COM_READ_ANDX? How does this parameter get set in
	> the SMB_COM_READ_ANDX command.
	>
	> The protocol I have negotiated is NT LM 0.12.
	>
	> Thanks
	>
	> Sailaja Josyula
	> Websphere Portal
	> IBM Software Group
	> Phone: 914-784-5472 Tie Line: 863-5472 Fax: 914-784-3833
	> sailaja at us.ibm.com
	
	--
	"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
	Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
	jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development,
	uninq.
	ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
	OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org