Bug 4779 - modification time inconsistency
Summary: modification time inconsistency
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.25b
Hardware: x64 Linux
: P3 normal
Target Milestone: none
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-11 15:20 UTC by Carlos Knowlton
Modified: 2007-07-13 08:32 UTC (History)
1 user (show)

See Also:

Attachments
Patch for 3.0.25b (1.35 KB, patch)
2007-07-11 20:50 UTC, Jeremy Allison 		no flags Details
Correct patch. (1.44 KB, patch)
2007-07-11 21:01 UTC, Jeremy Allison 		no flags Details
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Knowlton 2007-07-11 15:20:17 UTC 
Some Windows utilities rely on "touch"ing (changing the mod time on) zero-length files in a folder for the purpose of judging when that folder was last accessed.  This works fine on mapped windows servers, and from the local disk, but from a Samba (v3.0.22) volume, the mod time doesn't change unless there was an actual data change within the file.  (ie, when you select "save" in notepad, it should change the mod time of an empty file, even if you don't change the contents. From Samba, the mod time isn't changed without changing the contents.). 

Example software that relies on this functionality:
Wonderware SCADA software
Comment 1 Jeremy Allison 2007-07-11 20:50:12 UTC 
Created attachment 2809 [details]
Patch for 3.0.25b

I need to add a Samba4 torture test for this case to ensure we
understand the interactions with "last write".
Jeremy.
Comment 2 Jeremy Allison 2007-07-11 21:01:52 UTC 
Created attachment 2810 [details]
Correct patch.

This should be the correct patch - ignore the previous one. This one should play nicely with MS-Office.
Jeremy.
Comment 3 Jeremy Allison 2007-07-12 13:17:52 UTC 
Should be fixed with rev. 23855 - for 3.0.25c. Please re-open if not.
Jeremy.