[lkml]   [2005]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ctime set by truncate even if NOCMTIME requested
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).
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-19 23:06    [W:0.283 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site