cp -p fails to preserve time

[Jeremy Allison]

On Tue, Jul 31, 2018 at 05:56:32PM +0000, Rungta, Vandana wrote:
> Hello,
> 
>  
> 
> cp   -p   <file>  <smbshare>/<destfile>
> 
> fails to preserve the time on the copied file, when we send the request from a
> Linux client that mounts a Samba share on a Linux server because
> update_write_time_on_close resets the dest file time to the current time.
> 
>  
> 
> Tested with Samba 4.8.3
> 
>  
> 
> Open file for write (fsp1),
> 
> write data
> 
> write_file  -> mark_file_modified -> trigger_write_time_update -> sets
> update_write_time_on_close on fsp1
> 
> stat open fsp2
> 
> setinfo
> 
> vfs call ntimes_fn with mtime = source file time
> 
> close fsp2
> 
> close fsp1
> 
> update_write_time_on_close is set on fsp1
> 
> vfs call ntimes_fn with mtime = current time
> 
>  
> 
> $ ll sample.txt
> 
> -rw-rw-r-- 1 xxx xxx 458 May 18 21:15 sample.txt
> 
> $ ll smbshare/sample.txt
> 
> -rwxr-xr-x 1 root root 458 Jul 20 17:01 smbshare/sample.txt
> 
>  
> 
> Requests received from the client:
> 
>   smbd_smb2_request_dispatch: opcode[SMB2_OP_CREATE] mid = 76
> 
>   smbd_smb2_request_dispatch: opcode[SMB2_OP_CREATE] mid = 77   fsp1
> 
>   smbd_smb2_request_dispatch: opcode[SMB2_OP_GETINFO] mid = 78
> 
>   smbd_smb2_request_dispatch: opcode[SMB2_OP_WRITE] mid = 79
> 
>   smbd_smb2_request_dispatch: opcode[SMB2_OP_CREATE] mid = 80   fsp2
> 
>   smbd_smb2_request_dispatch: opcode[SMB2_OP_SETINFO] mid = 81
> 
>   smbd_smb2_request_dispatch: opcode[SMB2_OP_CLOSE] mid = 82    fsp2 closed
> 
>   smbd_smb2_request_dispatch: opcode[SMB2_OP_CREATE] mid = 83   fsp3
> 
>   smbd_smb2_request_dispatch: opcode[SMB2_OP_SETINFO] mid = 84
> 
>   smbd_smb2_request_dispatch: opcode[SMB2_OP_CLOSE] mid = 85    fsp3 closed
> 
>   smbd_smb2_request_dispatch: opcode[SMB2_OP_CREATE] mid = 86   fsp4
> 
>   smbd_smb2_request_dispatch: opcode[SMB2_OP_SETINFO] mid = 87
> 
>   smbd_smb2_request_dispatch: opcode[SMB2_OP_CLOSE] mid = 88    fsp4 closed
> 
>   smbd_smb2_request_dispatch: opcode[SMB2_OP_CLOSE] mid = 89    fsp1 closed
> 
>  
> 
> BTW:  If the share is mounted using vers=1.0 time is preserved.
> 
>  
> 
> Is this a known problem? Is there a workaround?
> 
>  
> 
> Potential solution options:
> 
>  1. Option in smb.conf  to set update write time on close = no (File systems
>     set their own mtime based on writes received)
>  2. Additional parameter to the vfs function ntimes_fn – to specify if the
>     write modification time was because of a client request or because of
>     update write time on close
>  3. Additional opens (fsp2, fsp3, etc) go look through all open handles on the
>     files and clear the update write time on close flag if there is a setinfo
>     request that updates the mtime.

What happens if you do the same set of operations to a Windows
server ? Does the same thing happen ? Once we know what
Windows does in this situation we can code up a client
test and then ensure smbd passes it.

My gut feeling is that the setinfo on the second handle
should overwrite the 'update write time on close' behavior,
but tests will show what the "correct" behavior is.

Jeremy.