Re: [NFS] [PATCH] NFS server does not update mtime on setattr request

[Peter Staubach <staubach@redhat.com>]

Trond Myklebust wrote:

> On Wed, 2006-06-07 at 11:26 -0400, Peter Staubach wrote:
>  
>
> > J. Bruce Fields wrote:
> >
> >    
> >
> > > On Wed, Jun 07, 2006 at 10:44:50AM -0400, Peter Staubach wrote:
> > >
> > >
> > >      
> > >
> > > > I saw that wording too and assumed what I think that you assumed.  I
> > > > assumed that that meant that if the new size is equal to the old size,
> > > > then nothing should be changed.  However, that does not seem to be how
> > > > those words are to be interpreted.  They are to be interpreted as "if
> > > > the new length of the file can be successfully set, then the
> > > > mtime/ctime should be changed".
> > > >   
> > > >
> > > >        
> > > What's the basis for that interpretation?  The language seems extremely
> > > clear:
> > >
> > > 	"On successful completion, if the file size is changed, these
> > > 	functions will mark for update the st_ctime and st_mtime fields
> > > 	of the file, and if the file is a regular file, the S_ISUID and
> > > 	S_ISGID bits of the file mode may be cleared."
> > >
> > > Why are you concerned about this?  Do you have an actual application
> > > that breaks?
> > >
> > >      
> > Yes, there is a customer who is quite unhappy that the semantics over Linux
> > client NFS are different than those of BSD, Solaris, and local file system
> > access on Linux itself.  The basis for my work is based on a bugzilla from
> > this customer.
> >
> > My interpretation is based on looking at the local behavior on Linux, which
> > changes mtime/ctime even if the file size does not change, and SunOS, which
> > changes mtime/ctime even if the file size does not change and is very
> > heavily SUSv3 compliant.
> >
> > In this case, "changed" does not mean "made different".  It simply means
> > that the file size is set to the new value.
> >
> > I would have chosen different words or a different interpretation too,
> > but all of the evidence suggests that the semantics are as I stated.
> >    
>
> We've already fixed this to be SuSv3 compliant for both create and
> truncate. Your "safe" suggestion would break truncate again. That is why
> it is being vetoed.

You are speaking of the client side changes?  I don't have a problem with
not taking them.

I am curious about how this would break truncate?

   Thanx...

      ps
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/