Fwd: SMB2 not respecting mtime values
Jacob Shivers
jshivers at redhat.com
Sat Jun 15 17:37:48 UTC 2019
Also confirming that mtime is preserved when copying to a Windows 2k19 server.
Windows OS pre 2k16 and 10 are impacted and Samba is impacted.
On Thu, Jun 13, 2019 at 4:56 PM Steve French <smfrench at gmail.com> wrote:
>
> I verified that Jacob is correct. Works (mtime preserved) to Windows
> 10 server, but fails to Samba 4.10 server (mtime not preserved after
> being set).
>
> On Wed, Jun 12, 2019 at 11:19 AM Jacob Shivers <jshivers at redhat.com> wrote:
> >
> > I finally got around to making some time for this and I this is indeed
> > a server side issue.
> > The SMB client is using the appropriate file handles when setting
> > atime and mtime and the server initially reports the desired mtime.
> > The server only slightly later reports a mtime matching that of ctime.
> >
> > $ tshark -tad -n -r cp_p-testing-3.16.66.pcap -Y 'smb2.pid == 0xf2d'
> > -T fields -e frame.number -e smb2.fid -e smb2.last_access.time -e
> > smb2.last_write.time -e _ws.col.Info -E header=y | tr '\t' '#' |
> > column -t -s '#'
> > frame.number smb2.fid
> > smb2.last_access.time smb2.last_write.time
> > _ws.col.Info
> > 170
> > Create Request
> > File: test_file-data
> > 171
> > Create
> > Response, Error: STATUS_OBJECT_NAME_NOT_FOUND
> > 173 00000000-0000-0000-0000-000000000000
> > Create Request
> > File: test_file-data
> > 174 5981ad82-0000-0000-1d86-2dcf00000000 May 27, 2019
> > 20:16:03.862513400 EDT May 27, 2019 20:16:03.862513400 EDT Create
> > Response File: test_file-data
> > 175 5981ad82-0000-0000-1d86-2dcf00000000
> > GetInfo Request
> > FILE_INFO/SMB2_FILE_INTERNAL_INFO File: test_file-data
> > 176
> > GetInfo
> > Response
> > 177 5981ad82-0000-0000-1d86-2dcf00000000
> > Write Request
> > Len:12 Off:0 File: test_file-data
> > 178
> > Write Response
> > 179
> > Create Request
> > File: test_file-data
> > 180 b8fa5b2d-0000-0000-d86e-38bf00000000 May 27, 2019
> > 20:16:03.862513400 EDT May 27, 2019 20:16:03.862513400 EDT Create
> > Response File: test_file-data
> > 181 b8fa5b2d-0000-0000-d86e-38bf00000000 Oct 31, 2018
> > 00:00:00.000000000 EDT Oct 31, 2018 00:00:00.000000000 EDT SetInfo
> > Request FILE_INFO/SMB2_FILE_BASIC_INFO File: test_file-data
> > 182
> > SetInfo
> > Response
> > 183 b8fa5b2d-0000-0000-d86e-38bf00000000
> > Close Request
> > File: test_file-data
> > 184 Dec 31, 1969
> > 19:00:00.000000000 EST Dec 31, 1969 19:00:00.000000000 EST Close
> > Response
> > 185
> > Create Request
> > File: test_file-data
> > 186 f7323833-0000-0000-5d04-6e1d00000000 Oct 31, 2018
> > 00:00:00.000000000 EDT Oct 31, 2018 00:00:00.000000000 EDT Create
> > Response File: test_file-data
> > 187 f7323833-0000-0000-5d04-6e1d00000000 Dec 31, 1969
> > 19:00:00.000000000 EST Dec 31, 1969 19:00:00.000000000 EST SetInfo
> > Request FILE_INFO/SMB2_FILE_BASIC_INFO File: test_file-data
> > 188
> > SetInfo
> > Response
> > 189 f7323833-0000-0000-5d04-6e1d00000000
> > Close Request
> > File: test_file-data
> > 190 Dec 31, 1969
> > 19:00:00.000000000 EST Dec 31, 1969 19:00:00.000000000 EST Close
> > Response
> > 191 5981ad82-0000-0000-1d86-2dcf00000000
> > Close Request
> > File: test_file-data
> > 192 Dec 31, 1969
> > 19:00:00.000000000 EST Dec 31, 1969 19:00:00.000000000 EST Close
> > Response
> >
> >
> > $ tshark -tad -n -r cp_p-testing-3.16.66.pcap -Y 'smb2.cmd == find' -O
> > smb2 | sed '/test_file-data/,/test_file-data/ !d'
> > FileIdBothDirectoryInfo: test_file-data
> > Next Offset: 0
> > File Index: 0x00000000
> > Create: May 27, 2019 20:16:03.862513400 EDT
> > Last Access: Oct 31, 2018 00:00:00.000000000 EDT
> > Last Write: May 27, 2019 20:16:03.872393500 EDT
> > Last Change: May 27, 2019 20:16:03.872393500 EDT
> > End Of File: 12
> > Allocation Size: 1048576
> > File Attributes: 0x00000020
> > .... .... .... .... .... .... .... ...0 = Read
> > Only: NOT read only
> > .... .... .... .... .... .... .... ..0. = Hidden: NOT hidden
> > .... .... .... .... .... .... .... .0.. = System:
> > NOT a system file/dir
> > .... .... .... .... .... .... .... 0... = Volume
> > ID: NOT a volume ID
> > .... .... .... .... .... .... ...0 .... =
> > Directory: NOT a directory
> > .... .... .... .... .... .... ..1. .... = Archive:
> > Modified since last ARCHIVE
> > .... .... .... .... .... .... .0.. .... = Device:
> > NOT a device
> > .... .... .... .... .... .... 0... .... = Normal:
> > Has some attribute set
> > .... .... .... .... .... ...0 .... .... =
> > Temporary: NOT a temporary file
> > .... .... .... .... .... ..0. .... .... = Sparse:
> > NOT a sparse file
> > .... .... .... .... .... .0.. .... .... = Reparse
> > Point: Does NOT have an associated reparse point
> > .... .... .... .... .... 0... .... .... =
> > Compressed: Uncompressed
> > .... .... .... .... ...0 .... .... .... = Offline: Online
> > .... .... .... .... ..0. .... .... .... = Content
> > Indexed: NOT content indexed
> > .... .... .... .... .0.. .... .... .... =
> > Encrypted: This is NOT an encrypted file
> > Filename Length: 28
> > EA Size: 60
> > Reserved: 00000000
> > File Id: 0x0000000000052b02
> > Filename: test_file-data
> >
> > I've added additional notes, strace, and pcap data to both kenel and
> > samba bugzillas that seem applicable to this:
> >
> > ** Bug 198967 - Modification times not preserved correctly **
> > https://bugzilla.kernel.org/show_bug.cgi?id=198967
> >
> > ** Bug 13594 - smbd write time handling differs compared to recent
> > Windows releases **
> > https://bugzilla.samba.org/show_bug.cgi?id=13594
> >
> > The earlier comments about filehandle do not apply as the atime used
> > the same filehandle and the filehandle used is what should be used for
> > compound operations.
> >
> > For context, Samba is matching behavior in Windows 2k16.
> >
> >
> > On Thu, Jan 24, 2019 at 5:49 PM Jeremy Allison <jra at samba.org> wrote:
> > >
> > > On Thu, Jan 24, 2019 at 05:47:24PM -0500, Jacob Shivers wrote:
> > > > On Thu, Jan 24, 2019 at 3:14 PM Ralph Böhme <slow at samba.org> wrote:
> > > > >
> > > > > On Thu, Jan 24, 2019 at 12:24:53PM -0500, Jacob Shivers wrote:
> > > > > >On Thu, Jan 24, 2019 at 12:11 PM Ralph Böhme via samba-technical
> > > > > ><samba-technical at lists.samba.org> wrote:
> > > > > >>
> > > > > >> On Thu, Jan 24, 2019 at 09:03:41AM -0800, Jeremy Allison via samba-technical wrote:
> > > > > >> >Maybe. Changing meta-data semantics on write is fraught with danger,
> > > > > >> >and we don't even do that for SMB1 unix extensions. So let's not
> > > > > >> >add contraints we don't understand yet please.
> > > > > >> >
> > > > > >> >My money is on a client bug, as always :-).
> > > > > >>
> > > > > >> fwiw, just in case you were not aware of this one:
> > > > > >>
> > > > > >> https://bugzilla.samba.org/show_bug.cgi?id=13594
> > > > > >>
> > > > > >> We also seem to have a bug that a set-eof on a handle with
> > > > > >> set-eof-size=existing-size doesn't flush a pending write time update. At least
> > > > > >> newer Windows server seem to do that.
> > > > > >
> > > > > >This seems like what the issue is.
> > > > > >The SMB server is uptime mtime after the server actually flushes to
> > > > > >stable storage.
> > > > >
> > > > > not quite, but still a client bug. :) The client uses a second handle to set the
> > > > > mtime, it should use the first handle. Or open the second handle after closing
> > > > > the first one where it did the write.
> > > >
> > > > Ahh.
> > > >
> > > > Thank you very much for your help and for narrowing down the problem
> > > > to a client side bug :)
> > >
> > > Bingo ! I claim my 5 euro :-) :-).
>
>
>
> --
> Thanks,
>
> Steve
More information about the samba-technical
mailing list