Re: Flush SMB Cache on Windows Vista?
- From: "boris" <somewhere@xxxxxxxxxxx>
- Date: Wed, 18 Feb 2009 13:25:35 -0800
Hello Jed,
Are you sure you aren't hitting this one: http://support.microsoft.com/kb/937082 ? - it describes Vista used as fileserver, but I imagine similar behavior would occur in Win2008 if there aren't enough CALs installed on the server.
Boris
"Jed" <jth_nospam_alias_2@xxxxxxxxxxxxxxxx> wrote in message news:6bf7df521a79a8cb5fe5b5e35732@xxxxxxxxxxxxxxxxxxxxxxx
Hello boris,
Thanks for the suggestion, Boris. I do believe that would do the job -- but that's a pretty large hammer. :) Unfortunately, I don't think that would be a viable workaround for us.
Jed"Jed" <jth_nospam_alias_2@xxxxxxxxxxxxxxxx> wrote in message
news:6bf7df521a71d8cb5f274f97aaf1@xxxxxxxxxxxxxxxxxxxxxxx
The short version of my question is: Is there an API call that willA workaround (an ugly one though) would be to reconnect to the network
dump
the SMB cache on Windows Vista when SMB 2.0 is used for Windows
Networking?
There may be alternatives to dumping the cache that I haven't
considered,
so allow me to offer a bit of (simplified) background: We have a
multi-user software, where multiple users may be simultaneously
creating,
opening, and accessing files on a shared drive. We have found then
when
our users upgrade their file servers to Server 2008, and they access
the
share from Windows Vista, the following scenario may occur: A file
is
created on a shared drive by User A. User B gets notification that
the
file has been created, so user B attempts to open that file. In most
cases, this works properly. But, sometimes (probably dependent on
cache
refresh timing), User B's attempts to open the file fail with an
error 2.
I have replicated a replicated a simplified version of this test case
in
our test environment and I have found that when User B receives the
error
2 (file not found), no SMB2 traffic appears on the wire. That, and
the
fact that this only occurs when Windows Vista and Server 2008 are
involved
tells me the caching in SMB2 is causing the client to return the
failure
based on cached directory information.
Up until this point, I have attempted several alternate ways of
attempting
to refresh the cache on demand: I've attempted to use the following
methods to "force" the cache to update, or traffic to go across the
wire:
- Call _access or GetFileAttributes (simply test for file existence).
-
CreateFile (tested specifying dwCreationDisposition of both
CREATE_NEW and
OPEN_EXISTING). Using OPEN_EXISTING behaves the same as
GetFileAttributes. CREATE_NEW does work properly -- but creating a
file
and then cleaning it up when the file is not present is not a good
workaround.
- GetFileInformationByHandleEx also seems to bypass the cache and can
provide up-to-date information on file existence -- but even when
file
existence has been confirmed by GetFileInformationByHandleEx, the
file
open still fails, so I doubt the cache is being updated.
Sorry for the lengthy post; but I wanted to detail what I've already
tried. Does anyone have any other workarounds to try? Aside from
other
workarounds, it would be ideal for us to have an API that will force
the
SMB cache to flush. Does any such API exist?
Jed
share
in question.
It could be done by a batch file:
net use \\servername\sharename /d
net use \\servername\sharename
It can also be done via Net Win32 APIs:
WNetCancelConnection2
http://msdn.microsoft.com/en-us/library/aa385427(VS.85).aspx
WNetAddConnection2
http://msdn.microsoft.com/en-us/library/aa385413(VS.85).aspx
Boris
.
- Follow-Ups:
- Re: Flush SMB Cache on Windows Vista?
- From: Jed
- Re: Flush SMB Cache on Windows Vista?
- References:
- Re: Flush SMB Cache on Windows Vista?
- From: boris
- Re: Flush SMB Cache on Windows Vista?
- From: Jed
- Re: Flush SMB Cache on Windows Vista?
- Prev by Date: Re: Flush SMB Cache on Windows Vista?
- Next by Date: Re: connect, socket API, is sending the connection request after long delay
- Previous by thread: Re: Flush SMB Cache on Windows Vista?
- Next by thread: Re: Flush SMB Cache on Windows Vista?
- Index(es):
Relevant Pages
|
