Bug 49600 - Delayed Samba server timestamp (stat) update serving to Windows
Delayed Samba server timestamp (stat) update serving to Windows
Product: Red Hat Linux
Classification: Retired
Component: samba (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-07-21 01:59 EDT by Donald Whisnant
Modified: 2007-04-18 12:34 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-09 13:01:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Donald Whisnant 2001-07-21 01:59:27 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2smp i686)

Description of problem:
I have a Samba server setup on my RH Linux 7.1 box and am using shares to
serve user directories to a Win2000 machine.  When a file is modified using
the Windows machine, there is a delay until the Linux box (Samba) reports
the correct new file timestamp to Windows.

For ordinary file editing, this isn't a problem, but when using a
development environment on the Windows machine, such as VC++ 6.0, you can
modify a file, save it, hit compile, and Windows won't even bother
recompiling the file because it thinks it hasn't changed (because the file
stat info has been delayed).  Several minutes later, VC++ says that the
file was modified outside of VC++ (though it hasn't -- just the file stat
was delayed).

I've tried syncing the time clocks between the two machines, but it seems
to make no difference.  The delay is always several minutes.  My current
remedy is to delete object files prior to compiling any changes, but that
delays the process, is very annoying, and is subject to error.

I've searched through all possible Samba settings and can't find anything
that relates to it.  Also, I'm not totally sure if it is Samba itself or a
cache/flush delay in the Linux filesystem itself.

I've already turned off oplocks, because they were giving problems when
compiling exe files during debug/modify sessions.

How reproducible:

Steps to Reproduce:
1.Setup samba server on Linux and use Win2000 as client
2.Place an entire VC++ project (already compiled and complete) on a share
of the Linux box
3.Bring up the project under VC++ 6.0 on the Win2000 box
4.Modify one of the source files of the project and save it.
5.Hit compile. Compiler thinks all files are current and won't compile
6.Wait several minutes.
7.VC++ will popup a message saying file was modified outside VC++.  (Saying
'yes' to reload it has no affect since the file on disk and in memory are
already in sync)
8.Hit compile again.  This time it compiles.
9.Also has been seen when using a Win95 OSR2 client.

Actual Results:  In performing these steps, there is a delay until
Windows realizes the file on the Linux server has changed causing
compilation problems.

Expected Results:  File timestamp as reported by Samba should have changed
instantly when the file was saved by Windows.

Additional info:

Samba version: samba-2.0.10-2
Red Hat version: 7.1
Windows version: 2000 sp1
VC++ version: 6.0 enterprise sp5
Comment 1 Trond Eivind Glomsrxd 2001-07-23 11:42:03 EDT
Can you try the samba package in Rawhide, and see if that solves your problem? 

I don't have access to WinMe or VC++, so a testcase without these components
would be appreciated.
Comment 2 Donald Whisnant 2001-07-23 22:53:58 EDT
Actually it is Win2000 instead of WinME.  But, anyway I updated to samba-2.2.1a-2 from rawhide and ran several tests but the problem is still there.

The more I observe it, the more it appears to be Windows or maybe the interaction between Windows and Samba.  I've noticed that explorer windows 
opened on samba mounted mapped drives (as this is) don't update themselves automatically when a file is changed (you have to refresh the window).  
Unlike the way a "native" Windows share does.  I'm thinking that perhaps Samba is behaving correctly, but Windows isn't updating its copy of stat info 
correctly.  Or maybe Samba isn't notifying Windows of the change.

Does anyone know if there are any Samba (or Windows) settings to control this?

Comment 3 Trond Eivind Glomsrxd 2001-07-23 23:15:45 EDT
Try the advice at

I suggest you ask on one of the samba mailing lists - if you find a solution,
please report back.
Comment 4 Donald Whisnant 2001-07-24 00:39:04 EDT
Thanks for the link.  Between the info on that link and updating to 2.2.1a of Samba, the problem has gotten better (from several minutes to several 
seconds), but not totally gone away.  Appears to be more of a win2k problem.

I've left the status for this thread as "needinfo" hoping that someone will read this and know of some hidden, obscure, undocumented win2k registry 
setting tweak that will fix this (MS is bad about that).  And in the meantime, I'll just have to be extra careful when recompiling code to make sure that all of 
the necessary modules get compiled.

I found the following [seemingly related] info on the samba mailing list and trimmed it and included it here for others reading this thread.


List:     samba
Subject:  New file copy to samba share not display at Win2k Pro client?
From:     "Vincent W.S. Tam" <vincent.tam@aib.net>
Date:     2001-06-06 1:32:43

Dear all,

We're using Samba 2.0.7 on a Debian 2.2 Linux system using kernel 2.2.17.
Sometimes when we copy files to the samba share from one of our Win2k Pro
client, we could not see the file appear at another Win2k Pro client. We can
only see the file appear again in about 15mins later.

Our client with same system config has similar problem while some of their
files are completely invisible but we can find them out inside the Linux

Is there some sort of caching for the directory content either at the samba
or Win2k Pro? Or it is a bug for the 2.0.7 release?

Thanks a lot for your help!



Subject:  RE: New file copy to samba share not display at Win2k Pro
From:     "Kristof Hardy" <kristof.hardy@mediamine.com>
Date:     2001-06-06 6:01:24


We also have the 'problem' that the auto-refresh (can be forced by F5 in
win2k explorer) doesn't always work that good in Windows Explorer.. Hitting
F5 does the job, but still it's a different behavior then NT or Win2k native



Subject:  Re: New file copy to samba share not display at Win2k Pro
From:     tpot@samba.org (Tim Potter)
Date:     2001-06-06 6:06:08

In the Samba 2.0 series the directory notification functions don't work
particularly well.  If you have a Linux 2.4 kernel and use Samba 2.2
this should work must better.  Tridge added kernel based directory
notification sometime in the 2.3 kernel series and the associated 
support to Samba.  

If you run ./configure and see a line like "checking for kernel change 
notify support... yes" then the new directory notification code is
being used.


- - - - - - - -

List:     samba
Subject:  Directory Refresh
From:     "Rich Fernandez" <rfernandez@arrow.com>
Date:     2001-05-08 19:22:57


I just installed 2.2.0 on AIX 4.3.3 and created a share for test purposes.
Clients will be connecting from NT4 clients.
Someone has written a Visual C++ app that at one point does a dir on the
mapped Samba drive.

I've found articles discussing a similar problem, but have been unableto
find a solution that works for me.
The problem manifests like this:
1) Create a file in the shared unix directory
2) Run the C++ app (dir)
3) File is not found
4) wait a few (2 or 3) seconds
5) dir
6) File is found

This delay is not acceptable, and neither is coding a "sleep" into the
program before it does its dir.

I've changed the "change notify timeout" parameter from the default of 60 to
a value of 5, but this had no effect on performance.

I'm at a loss as to what else to try. Can anyone provide assistance?
I can provide smb.conf or output of testparm if it would help


Comment 5 Trond Eivind Glomsrxd 2002-07-25 12:05:02 EDT
Closing, as the 2.0.1a was said to make the problems less and it being more of a
win2k problem.

Note You need to log in before you can comment on or make changes to this bug.