[PATCH] CIFS: Update CreationTime on every query info request
jlayton at samba.org
Wed Aug 6 06:08:33 MDT 2014
On Wed, 6 Aug 2014 15:59:22 +0400
Pavel Shilovsky <pshilovsky at samba.org> wrote:
> 2014-08-06 15:25 GMT+04:00 Jeff Layton <jlayton at samba.org>:
> > On Wed, 6 Aug 2014 15:15:43 +0400
> > Pavel Shilovsky <pshilovsky at samba.org> wrote:
> >> Samba server can change a creation time of an inode in the default
> >> configuration. The client sets this value during the inode initialization
> >> only and uses it the inode search. In this case harlinked dentries may
> >> link to different inodes. As the results the Cthon basic test #7 fails
> >> on nounix Samba mounts.
> >> Fix this by making the client update the creation time on every
> >> query info request.
> >> Cc: Jeff Layton <jlayton at samba.org>
> >> Signed-off-by: Pavel Shilovsky <pshilovsky at samba.org>
> >> ---
> >> fs/cifs/inode.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
> >> index a174605..2029e7c 100644
> >> --- a/fs/cifs/inode.c
> >> +++ b/fs/cifs/inode.c
> >> @@ -173,6 +173,9 @@ cifs_fattr_to_inode(struct inode *inode, struct cifs_fattr *fattr)
> >> cifs_i->cifsAttrs = fattr->cf_cifsattrs;
> >> + /* Samba server changes this value in the default configuration */
> >> + cifs_i->createtime = fattr->cf_createtime;
> >> +
> >> if (fattr->cf_flags & CIFS_FATTR_NEED_REVAL)
> >> cifs_i->time = 0;
> >> else
> > NAK
> > That really sounds more like a bug in Samba. The creation time is
> > supposed to be immutable, and if it changes then that means that you
> > have a new inode.
> > We really *don't* want to go updating it like this.
> If it is suppose to be immutable and the server does processing right,
> the fix will not break things since the cifs_i->createtime value stays
> the same.
Does anything prevent a server from reusing a uniqueid? If not, then
this is one of the only mechanisms to tell whether this is the same
inode as the previous one or a new one.
> But if this value was changed and we don't store this latest returned
> value from the server and continue to use the old one, does things go
> better? We'll end up relying on the value that is wrong...
We rely on the server to send us valid information. If the server
doesn't do that, then it's a server bug.
> If Samba server doesn't store the creation time attribute in xattrs
> (that is restricted by underlying file system and switched off by
> default), it can't return a right value to the client since POSIX file
> systems store only access, modify and change timestamps.
Yep, faking up valid fields like this is always iffy.
> So, in the result we have the CIFS client that doesn't work with the
> default configuration of Samba. If we can't fix Samba due to POSIX
> restrictions), we need to do something with the client, don't we?
Well, no. The default configuration of samba has unix extensions
enabled, and with that the create time is ignored (since it's not
returned at all in that case).
Jeff Layton <jlayton at samba.org>
More information about the samba-technical