> Is is proper semantics to allow:
>
> open("blah blah", O_RDONLY | O_TRUNC)
>
> ? Because we do. Just an observation.
Single UNIX Specification says tht "The result of using O_TRUNC with
O_RDONLY is undefined." (I don't have access to any other specs.)
There are some things to be careful of (e.g. making sure that the
truncation is ineffective for read-only files), but Linux does seem to
handle this (fs/open.c:do_open()). It also ignores requests to
truncate immutable or append-only files (fs/ext2/truncate.c), though
i_op->truncate() never returns an error on linux...
Hans-Joachim Widmaier <hjwidmai@foxboro.com> sent a month ago a patch
to allow i_op->truncate() to return error codes. I have to admit I
haven't applied his patch (it overlaps with another patch), but I'd
like for his patch to be applied. truncate() can fail, and the user
ought to be informed if it has failed. I think tht the Single Unix
Specification requires this: "Upon successful completion, ftruncate()
and truncate() return 0. Otherwise a -1 is returned, and errno is set
to indicate the error."
pjm.
(I've been told to give the following URL when citing from Single UNIX
Specification:
<http://www.opengroup.org/public/pubs/catalog/x912.htm>.)