Re: ctime set by truncate even if NOCMTIME requested

[Steve French <smfrench@austin.rr.com>]

Trond Myklebust wrote:

>It is quite correct for the kernel to request that the filesystem set
>ctime/mtime on successful calls to open(O_TRUNC).
>  http://www.opengroup.org/onlinepubs/009695399/toc.htm
>  
>
I agree that it is correct to set ctime/mtime here, just not convinced 
it it worth setting it twice which is what will happen for non-local fs.

client truncate -> client setattr(for both size and ctime) -> server 
setattr (which will have a sideffect of ctime to be set on the server, 
not just the change to file size) and then another call to the server to 
set the ctime (which will end up setting ctime twice - one to the 
(correct) server's time and once to the less correct client's time.

Problem is I can't tell the difference inside the fs between the case of 
an application that needs to set ctime explicitly to something different 
than the server would want (e.g. presumably the touch utility) and 
something which can be ignored.    I noticed this when I found a server 
(windows me) that was returning an error for setting timestamps - and 
this was causing errors to be returned to truncate.  In this case 
(server refusing to let the client fs (re)set the timestamps), I would 
like to return an error on touch, but succeed on truncate but I don't 
see a way to tell the difference reliably.