linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Anton Altaparmakov <aia21@cam.ac.uk>
Cc: Neil Brown <neilb@suse.de>, Christoph Hellwig <hch@lst.de>,
	Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [2.6 PATCH]: Incorrect lack of {m,c}time modification for ftruncate.
Date: Sun, 12 Mar 2006 12:22:57 -0500	[thread overview]
Message-ID: <1142184177.32707.10.camel@lade.trondhjem.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0603121544050.14340@hermes-2.csi.cam.ac.uk>

On Sun, 2006-03-12 at 16:28 +0000, Anton Altaparmakov wrote:
> Hi,
> 
> Recently Neil Brown's patch to fix the standards compliance of setting 
> {m,c}time on {f,}truncate and open(O_TRUNC) was applied to the kernel.
> 
> See 
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a30131e7dbb17e5fec6958bfac9da9aff1fa29b
> 
> From the patch description:
> <quote>
> SUS requires that when truncating a file to the size that it currently
> is:
>   truncate and ftruncate should NOT modify ctime or mtime
>   O_TRUNC SHOULD modify ctime and mtime.
> [snip]
> With this patch:
>   ATTR_CTIME|ATTR_MTIME are sent with ATTR_SIZE precisely when
>     an update of these times is required whether size changes or not
>     (via a new argument to do_truncate).  This allows NFS to do
>     the right thing for O_TRUNC.
>   inode_setattr nolonger forces ATTR_MTIME|ATTR_CTIME when the ATTR_SIZE
>     sets the size to it's current value.  This allows local filesystems
>     to do the right thing for f?truncate.
> </quote>
> 
> The problem with this patch is that the standard does not actually say the 
> above, it in fact says that:
> 
> - both open(O_TRUNC) and ftruncate() _always_ modify {m,c}time and 
> 
> - truncate() modifies {m,c}time _only_ if the file size changes due to the 
> truncate.
> 
> (This IMO is completely brain damaged... but I guess no-one claims 
> standards are not braindamaged...)
> 
> Here are the relevant three pages from posix/sus3 together with the 
> relevant paragraph quoted:
> 
> http://www.opengroup.org/onlinepubs/009695399/functions/open.html
> <quote>
> If O_TRUNC is set and the file did previously exist, upon successful 
> completion, open() shall mark for update the st_ctime and st_mtime fields 
> of the file.
> </quote>
> 
> http://www.opengroup.org/onlinepubs/009695399/functions/ftruncate.html
> <quote>
> Upon successful completion, if fildes refers to a regular file, the 
> ftruncate() function shall mark for update the st_ctime and st_mtime 
> fields of the file and the S_ISUID and S_ISGID bits of the file mode may 
> be cleared. If the ftruncate() function is unsuccessful, the file is 
> unaffected.
> </quote>
> 
> http://www.opengroup.org/onlinepubs/009695399/functions/truncate.html
> <quote>
> Upon successful completion, if the file size is changed, this function 
> shall mark for update the st_ctime and st_mtime fields of the file, and 
> the S_ISUID and S_ISGID bits of the file mode may be cleared.
> </quote>
> 
> So at present we handle open(O_TRUNC) and truncate() correctly but we do 
> the Wrong Thing (TM) for ftruncate().
> 
> This is fixed by the simple one liner patch at the bottom of this email.
> 
> Please apply or tell me that I can't read the standard and kindly point 
> out to me what I have missed...  (-:

The page for ftruncate() appears to be a tad self-contradictory. In the
"Issue 6" text at the bottom of the page it appears to say that S_ISUID
and S_ISGID are only changed if the file size is changed.

I also had a look at the Solaris manpages: they say that ftruncate()
changes st_mtime/st_ctime and clears S_ISUID/S_ISGID only if the file
size changes (which would make it act just like truncate()).

Cheers,
  Trond


      reply	other threads:[~2006-03-12 17:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-12 16:28 [2.6 PATCH]: Incorrect lack of {m,c}time modification for ftruncate Anton Altaparmakov
2006-03-12 17:22 ` Trond Myklebust [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1142184177.32707.10.camel@lade.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=aia21@cam.ac.uk \
    --cc=akpm@osdl.org \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).