Silly reads from WinXP/OfficeXP against Samba 3.0
kalele at veritas.com
Tue Jul 15 17:23:02 GMT 2003
Another thing to look for is whether 'client-side offline caching' is
switched on. The CSC daemon on clients does independent tree-connects and
reads files in to cache them. Later, it periodically tree-connects again
to check whether the timestamps on the cached files have changed on the
There used to be a bug in Samba where the CSC daemon would get the
impression that the size on the file had changed; the values returned in
queryfileinfo and ntcreat&x wouldn't match (afair), but this was fixed at
the time in all existing branches.
On Tue, 15 Jul 2003, Christopher R. Hertel wrote:
>Does the same happen against an NT or W2K server?
>We've seen similar (not the same) behavior in other cases. There's
>"rabbit-pellet" mode, in which Windows Explorer on a W/98 or ME client
>will do short writes (512 bytes), each followed by a flush operation. It
>is still not clear what triggers this.
>I can send you a capture if you'd like to see it.
>The problem with rabbit-pellet mode is that no one has ever seen Windows
>systems do this to one another. It only happens against a third-party
>server (Samba, generally, but it may happen against others...dunno).
>It *seems* as though rabbit-pellet mode is triggered by pass-through
>authentication on the server, but it is not consistent. There may also be
>timing issues involved.
>So, the thing to figure out first is whether or not XP does the same thing
>against other servers. If so, we may be able to get Microsoft to fix the
>bug that causes it. If it only happens against Samba, then we need to
>figure out what we are doing that is "different".
>As with much of Microsoft's code, it is likely that we're just causing
>Windows to wander down some untested code path. These are probably bugs
>that have never been tested because none of Microsoft's products exercise
>them. I doubt that this behavior is intentional.
>On Tue, Jul 15, 2003 at 04:27:48PM +0200, Volker Lendecke wrote:
>> Here I have a repeatable case: Office XP SP2 on WinXP reads a file, and
>> during the first requests everything looks fine. Then after some time
>> the machine starts to read *HUGE* amounts of 512 byte-fragments from the
>> .doc-file. This results in ~140000 packets whereas the same operations
>> only use ~4000 packets when the file is on 2k.
>> I already tried 'max xmit = 4356' to match 2k buffer size negotiation,
>> but that did not help. One thing that I also found is that the client
>> seems to actively use the multi-request feature of 2k.
>> I can provide sniffs and tests with a patched Samba, but I'm currently a
>> bit lost. Staring at a dump of 140000 packets is not exactly easy :-(
>> Any idea anybody?
>"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
More information about the samba-technical