[CIFS] Fix mtime on cp -p when file data cached but written out too late

Kukks noticed that cp -p can write out file data too late, after the timestamp
is already set. This was introduced as an unintentional sideeffect of the change
in an earlier patch (see below) which fixed some delayed return code propagation.

cea218054ad277d6c126890213afde07b4eb1602
Author: Jeff Layton <jlayton@redhat.com>
Date: Tue Nov 20 23:19:03 2007 +0000

Acked-by: Shirish Pargaonkar <shirishp@us.ibm.com>
Acked-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>

+5 -4
+5 -4
fs/cifs/inode.c
··· 1420 1420 } 1421 1421 cifsInode = CIFS_I(direntry->d_inode); 1422 1422 1423 - /* BB check if we need to refresh inode from server now ? BB */ 1424 - 1425 - if (attrs->ia_valid & ATTR_SIZE) { 1423 + if ((attrs->ia_valid & ATTR_MTIME) || (attrs->ia_valid & ATTR_SIZE)) { 1426 1424 /* 1427 - Flush data before changing file size on server. If the 1425 + Flush data before changing file size or changing the last 1426 + write time of the file on the server. If the 1428 1427 flush returns error, store it to report later and continue. 1429 1428 BB: This should be smarter. Why bother flushing pages that 1430 1429 will be truncated anyway? Also, should we error out here if ··· 1434 1435 CIFS_I(direntry->d_inode)->write_behind_rc = rc; 1435 1436 rc = 0; 1436 1437 } 1438 + } 1437 1439 1440 + if (attrs->ia_valid & ATTR_SIZE) { 1438 1441 /* To avoid spurious oplock breaks from server, in the case of 1439 1442 inodes that we already have open, avoid doing path based 1440 1443 setting of file size if we can do it by handle.