Re: Fwd: SMB2 not respecting mtime values

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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



[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux