lkml.org 
[lkml]   [2006]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [NFS] [PATCH] NFS server does not update mtime on setattr request
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/

\
 
 \ /
  Last update: 2006-06-07 17:47    [W:1.033 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site