Hide Forgot
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:
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.