Re: [2.6 PATCH]: Incorrect lack of {m,c}time modification for ftruncate.

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

 



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

-
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]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux