Created attachment 518631 [details]
Patch for the samba3x-3.3.8-0.52 SRPM to use the newer timestamp of a directory
Description of problem:
After some time of smbd running pressing F5 or choosing Refresh in the
windows explorer does not lead to a real refresh, when files have added
to a directory (or deleted) on Unix level i.e. not via Samba. In a tcpdump
i see old timestamps sent as Last Write and Change time of the directory,
Created: Aug 16, 2011 14:08:04.000000000
Last Access: Aug 16, 2011 14:15:23.142239000
Last Write: Aug 16, 2011 14:01:54.255351000
Change: Aug 16, 2011 14:01:54.255351000
So my suspicion is, windows "thinks" (as far as this term is applicable),
that the directory has not changed and thus does not query the contents
again (it really does not, can be seen in the tcpdump and in the strace
of the respective smbd). So one does not see the newly created file on
windows (from 14:08:04 (!?!)) or deleted files are still displayed.
Looking at the code i see, that when there is a cached write_time_ts
obtained in the function get_file_infos (in locking/locking.c) from
the share_mode tdb memory (or what it is), it overrides the value
of the actual file's st_mtime determined in get_lanman2_dir_entry .
I don't know, why in the share mode structure the timestamp is that
old and not updated. However, this procedure surprises me. Frankly
i'd prefer the actual mtime value obtained from the filesystem. If
this is not desired for whatever reason, i'd suggest to use the newer
i.e. later timestamp from both values. This is what the attached
patch (for samba3x-3.3.8-0.52) does.
As this problem occurs only after a notable uptime of the samba
server, i suspect, that there is actually a problem in the tdb code
or wherever the get_file_infos obtains the write_time_ts. In this
case the suggested patch is only a workaround. Anyway it works for me.
Additional Info: In the samba3x-3.5.4-0.83 (the current update) the
algorithm is spread a bit differently across the code. Nonetheless
the write_time from the share mode memory still overrides the mtime
from the filesystem (function smbd_dirptr_get_entry in source3/smbd/dir.c,
lines 984-987). Same applies for Samba 3.6.0.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Let Samba run for a certain time under notable load (exact values cannot be given, sorry)
2. Look at a directory on windows (2003 or 7) e.g. in the "Explorer"
3. Create a new file in the directory on Unix level (not through samba)
4. Refresh the view in the windows explorer or wait for auto-refresh
New file does not show up on windows, not even after hours
New file is visible on windows
3.3.8-0.52 is already a bit dated, have you retried with the samba update in RHEL5.7 ?
Not yet, sorry. The update must be done in a controlled rollout process.
I guess, the problem cannot be seen under low load, but will try that
nonetheless. Even in highly loaded production environment the problem shows
up finally after several days. The next change cycle in our production
environment will be in November.
Upgraded to samba3x-3.5.4-0.83.el5_7.2 2 weeks ago
(can be done during operation cause i have a tcp balancer before
2 backend samba servers)
Have seen several messages in the logs when starting after the
update, regarding tdb, telling about
fixing stale or inconsistent files (or similar, don't remember
exactly and the logs are rotated away now, damn)
No problem until now.
If the problem stays away, i'll close this report in November.
Seems, the problem is gone with samba3x-3.5.4-0.83.el5_7.2
(who comes with some changed defaults causing other trouble)
Thanks for testing. As this is fixed in our current released version, I'm closing this bug.