Bug #13299
closedFile mtime changes twice, when file is modified using SMB server
100%
Description
When working on files located on smb share served by illumos smb server, editors monitoring for file changes detecting changes, where are no.
Editors like notepad++ or eclipse behave unexpected, also make utils are affected.
The mtime changes after some seconds again, even if the changing program has already terminated.
here a sample from cygwin, demonstrating the behavior:
$ echo test > z:\\testtime2.txt && stat -c "after test program : %y" z:\\testtime2.txt && sleep 20 && stat -c "after additional 20s : %y" z:\\testtime2.txt
after test program : 2020-11-09 16:10:08.482197400 +0100
after additional 20s : 2020-11-09 16:10:08.484312500 +0100
Files
Related issues
Updated by Florian Manschwetus over 2 years ago
I managed to get some dtrace of smb_vop_ functions and I see some ops among them a setattr some time after the test program has ended.
I'll try to get into details of this ops.
Updated by Florian Manschwetus over 2 years ago
It looks a bit like the close operations happen twice
Updated by Florian Manschwetus over 2 years ago
- File dtraceOutNP++.txt dtraceOutNP++.txt added
- File dtraceOutTestProg.txt dtraceOutTestProg.txt added
I managed to put together some dtrace showing the unexpected explicit mtime change.
Also I used some test program, not doing that much after completing file op.
In summary, the programs alter and close the file, then they record the mtime.
Some seconds later a second smb close op happens, explicitly setting the mtime.
Updated by Florian Manschwetus over 2 years ago
I did some further dtrace research and was able to track it down to a specific code section, forcing mtime change on close in error here, I think.
Updated by Florian Manschwetus over 2 years ago
The problem is easy to reproduce with np++, open txt file, change sth, safe, change sth again, do not safe, switch window, maybe wait some/several seconds, switch back.
If interested I can share my dtrace stuff.
Updated by Florian Manschwetus over 2 years ago
Ok I disabled the code as Gordon has suggested, seems to solve the problem for now.
Would be good if someone can check in detail, if this code is more than really needed to meet the specs or if the f_written bit was set when it should not.
Additionally I'd like to mention, that I haven't found the initializer for this yet, maybe it is as simple as this.
Here the diff of the provisional fix:
diff --git a/usr/src/uts/common/fs/smbsrv/smb_ofile.c b/usr/src/uts/common/fs/smbsrv/smb_ofile.c
index d5388037c3..6f9e839e24 100644
--- a/usr/src/uts/common/fs/smbsrv/smb_ofile.c
+++ b/usr/src/uts/common/fs/smbsrv/smb_ofile.c
@@ -505,12 +505,14 @@ smb_ofile_close(smb_ofile_t *of, int32_t mtime_sec)
* during the close. Windows expects this.
* [ MS-FSA 2.1.5.4 "Update Timestamps" ]
*/
+#if 0
if (of->f_written &&
(pa->sa_mask & SMB_AT_MTIME) == 0) {
pa->sa_mask |= SMB_AT_MTIME;
gethrestime(&now);
pa->sa_vattr.va_mtime = now;
}
+#endif
if (of->f_flags & SMB_OFLAGS_SET_DELETE_ON_CLOSE) {
/* We delete using the on-disk name. */
Updated by Gordon Ross over 2 years ago
- Status changed from New to In Progress
- Assignee set to Gordon Ross
It looks like that update (during close) was from a possibly misunderstood section from a very old version of the MS-FSA spec.
The mtime update cases described in recent versions of MS-FSA appear to be handled well enough without this bit of code.
Updated by Gordon Ross over 2 years ago
Testing:
1: submitter verification
2: Windows protocol test suite BVT (no change)
Updated by Gordon Ross over 2 years ago
- Status changed from In Progress to Pending RTI
Updated by Electric Monk over 2 years ago
- Status changed from Pending RTI to Closed
- % Done changed from 0 to 100
git commit a8e9db1c816399e66d096a343815a6e845a7a0cd
commit a8e9db1c816399e66d096a343815a6e845a7a0cd Author: Gordon Ross <gordon.ross@tintri.com> Date: 2021-02-08T20:23:13.000Z 13299 File mtime changes twice, when file is modified using SMB server Reviewed by: Florian Manschwetus <manschwetus@cs-software-gmbh.de> Reviewed by: Andy Fiddaman <andy@omniosce.org> Reviewed by: Dominik Hassler <hadfl@omniosce.org> Approved by: Dan McDonald <danmcd@joyent.com>
Updated by Joshua M. Clulow over 1 year ago
- Related to Bug #2000: Wrong timestamp on files written over cifs added