Jeremy,

This is the case I mentioned in email.

Jeremy,

Looks like I have found the root cause.

In smbd_smb2_getinfo_send() after reading the file stat information, we are calling get_file_infos(). In this call we are basically trying to fetch the shared mode lock entry of the file/directory and storing the mtime as part of that entry.

get_file_infos(struct file_id id,
		    uint32_t name_hash,
		    bool *delete_on_close,
		    struct timespec *write_time)
{
	struct share_mode_lock *lck;

	if (delete_on_close) {
		*delete_on_close = false;
	}

	if (write_time) {
		ZERO_STRUCTP(write_time);
	}

	if (!(lck = fetch_share_mode_unlocked(talloc_tos(), id))) {
		return;
	}

	if (delete_on_close) {
		*delete_on_close = is_delete_on_close_set(lck, name_hash);
	}

	if (write_time) {
		struct timespec wt;

		wt = lck->changed_write_time;
		if (null_timespec(wt)) {
			wt = lck->old_write_time;
		}

		*write_time = wt;
	}

	TALLOC_FREE(lck);
}


And in smbd_do_qfilepathinfo() we have this check..

if (!null_timespec(write_time_ts) && !INFO_LEVEL_IS_UNIX(info_level)) {
		update_stat_ex_mtime(psbuf, write_time_ts);
	}

This check is getting passed and we end up updating the mtime with the write_time captured as part of get_file_infos(). Avoiding this check resolves the issue. But I am trying to understand the reason behind storing the old mtime  as part of get_file_infos().

The problem is that we don't call trigger_write_time_update*()
on the parent when creating files or subdirectories.

Maybe it's better to ignore the old write time from the locking.tdb
for directories.

Created attachment 8872 [details]
Patch for write time update.

Avoiding this check for directories seems good idea. Based on this I have actually modified update_stat_ex_mtime() to have this additional dir check. 

Attached the patch for the same. 

Please let me know if the patch looks fine.

Created attachment 9501 [details]
Test patch (not git format).

Can you try the following patch ? I think it's a cleaner and smaller fix, in that it simply means we don't store any old timestamp on open directory handles, which stops the "old timestamp hanging around" problem.

I'll write a torture test to check this and if it passes then I'll submit to master.

Jeremy.

(In reply to comment #5)
> Created attachment 9501 [details]
> Test patch (not git format).
> 
> Can you try the following patch ? I think it's a cleaner and smaller fix, in
> that it simply means we don't store any old timestamp on open directory
> handles, which stops the "old timestamp hanging around" problem.
> 
> I'll write a torture test to check this and if it passes then I'll submit to
> master.
> 
> Jeremy.

Jeremy,

I have tested this patch. It is working fine. 

Thanks,
Hemanth.

Created attachment 9502 [details]
git-am patch I've proposed for master.

Formal patch I've proposed for master, including test case.

Jeremy.

Created attachment 9513 [details]
git-am fix for 4.1.next and 4.0.next.

Updated with cherry-pick information from master.

Patches apply cleanly to 4.1.x, 4.0.x.

Jeremy.

(In reply to comment #8)
> Created attachment 9513 [details]
> git-am fix for 4.1.next and 4.0.next.
> 
> Updated with cherry-pick information from master.
> 
> Patches apply cleanly to 4.1.x, 4.0.x.
> 
> Jeremy.

Patch seems to be reviewed. Can I pick it for 4.1 and 4.0?

Yes please !

Re-assigning to Karolin for inclusion in 4.0.next, 4.1.next.

Jeremy.

Pushed to autobuild-v4-1-test and autobuild-v4-0-test.

Pushed to v4-1-test and v4-0-test.
Closing out bug report.

Thanks!