Re: ctime set by truncate even if NOCMTIME requested

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux