SMB_SET_FILE_BASIC_INFO

[Paul Heinz]

Michael wrote:
> I've been trying to get robocopy to work from an NT filesystem, copying
> to a Unix filesystem using Samba.  I finally figured out why it doesn't
> work.

Ah, this sounds familiar :-)

> In trans2.c/call_trans2setfilepathinfo(), the code that handles the
> SMB_SET_FILE_BASIC_INFO case takes the MAX of the write time and the
> changed time.  I believe Microsoft actually uses the changed (creation)
> time as the changed time of the file for the purposes of backups.  The
> write time is the last time the contents were changed.
>
> robocopy depends on being able to set the last write time.  If it fails,
> it doesn't know what to do the next time it is run.  Samba is forcing
> the time to be the latter of the write time and the creation time.
> Unfortunately, if a file is copied to a new location on NTFS, the write
> time is kept old and the creation time is set new.  This means that it
> is very easy to get a file in a state on NTFS such that copying it to a
> Samba server will set a relatively new modtime even thought the write
> time on NTFS is old.

A-ha! I think this explains the timestamp behaviour we've been seeing. The
original 2.0.5a code in trans2.c used a MIN() of the write time and changed
time and our files kept being sent back in time to a strange particular
timestamp value for each file. I assume this would have been the changed
timestamp NT stored as the file was copied from one of our NT servers onto
another (something we did when we ran out of space before moving to Linux).

> As an experiment, I changed the modtime computation in
> call_trans2setfilepathinfo to use only pdata+16 (write time) and ignore
> changed time (pdata+24) when handling SMB_SET_FILE_BASIC_INFO.  I think
> this works for me and may be what others want.  I doubt it works for
> everyone.  Does it deserve a mode in smb.conf?

Very interesting. It sounds like it may possibly solve our problem with the
incorrect timestamps even after applying the MIN vs. MAX patch. I'd be
interested to know how this plays out as I may make a similar patch to our
Samba codebase and turn back on NT smb support and see if 'all is well'.

FYI Michael, in case this doesn't prove to be the exact answer, you can also
turn off NT smb support in smb.conf and avoid this particular timestamp
issue whilst still using Samba which is what I did here at our site. If you
are using Backup Exec, you'll also need to change your SMB protocol level to
LANMAN2 to stop it freaking about failing NT smbs.

TTFN,
  Paul.