Bug 731289 - smbd sends old timestamps in a Trans2/FIND_FIRST2 Response
Summary: smbd sends old timestamps in a Trans2/FIND_FIRST2 Response
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: samba3x
Version: 5.6
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Guenther Deschner
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-17 09:44 UTC by Albert Flügel
Modified: 2011-12-05 14:32 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-05 14:32:43 UTC


Attachments (Terms of Use)
Patch for the samba3x-3.3.8-0.52 SRPM to use the newer timestamp of a directory (519 bytes, patch)
2011-08-17 09:44 UTC, Albert Flügel
no flags Details | Diff

Description Albert Flügel 2011-08-17 09:44:52 UTC
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,
in detail:
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):
3.3.8-0.52

How reproducible:

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
  
Actual results:
New file does not show up on windows, not even after hours

Expected results:
New file is visible on windows

Additional info:

Comment 2 Guenther Deschner 2011-09-30 15:21:23 UTC
3.3.8-0.52 is already a bit dated, have you retried with the samba update in RHEL5.7 ?

Comment 3 Albert Flügel 2011-10-06 07:51:53 UTC
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.

Comment 5 Albert Flügel 2011-10-18 14:15:17 UTC
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.

Comment 8 Albert Flügel 2011-11-09 10:38:25 UTC
Seems, the problem is gone with samba3x-3.5.4-0.83.el5_7.2
(who comes with some changed defaults causing other trouble)

Comment 9 Andreas Schneider 2011-12-05 14:32:43 UTC
Thanks for testing. As this is fixed in our current released version, I'm closing this bug.


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