From: "Michael Kerrisk" <mtk-lists@jambit.com>
To: <aebr@win.tue.nl>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: Bug in open() function (?)
Date: Thu, 17 Jul 2003 09:54:11 +0200 [thread overview]
Message-ID: <008f01c34c38$9be3c120$c100a8c0@wakatipu> (raw)
> > On Fri, 11 Jul 2003 22:23:00 PDT, Andrew Morton said:
> >
> > > We've lived with it for this long.
> >
> > Well... you have a point there..
> >
> > > Given that the behaviour is undefined, the behaviour which we should
> > > implement is clearly "whatever 2.4 is doing". So let's leave it
alone.
> >
> > I suppose I could live with that *IF* somebody fixes 'man 2 open' to
> > reflect reality.
>
> Corrections and additions to manpages are always welcome.
> Mail to aeb@cwi.nl .
>
>
> (Concerning the topic under discussion, the man page says
>
> O_TRUNC
> If the file already exists and is a regular file
> and the open mode allows writing (i.e., is O_RDWR
> or O_WRONLY) it will be truncated to length 0. If
> the file is a FIFO or terminal device file, the
> O_TRUNC flag is ignored. Otherwise the effect of
> O_TRUNC is unspecified.
>
> which is precisely right. It continues
>
> (On many Linux versions it
> will be ignored; on other versions it will return
> an error.)
>
> where someone may read this as if this is an exhaustive list of
> possibilities. So adding ", or actually do the truncate" will
> clarify.)
>
>
> Concerning the desired behaviour: if I recall things correctly
> doing the truncate was old SunOS behaviour, not doing it,
> that is, honouring the O_RDONLY, is new Solaris behaviour.
> Maybe someone with access to such machines can check.
>
> Software exists that does O_RDONLY | O_TRUNC.
A late addition to this thread, but all of these systems DO truncate with
O_RDONLY | O_TRUNC:
Solaris 8
Tru64 5.1B
HP-UX 11.22
FreeBSD 4.7
Although this flag combination is left unspecified by SUSv3, I don't
know of an implementation that DOESN'T truncate in these circumstances.
Cheers
Michael
next reply other threads:[~2003-07-17 7:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-17 7:54 Michael Kerrisk [this message]
2003-07-17 10:54 ` Bug in open() function (?) Andries Brouwer
-- strict thread matches above, loose matches on Subject: below --
2003-07-12 1:17 [PATCH] [2.5] adding ppp xon/xoff support Samuel Thibault
2003-07-12 1:30 ` Paul Mackerras
2003-07-12 2:42 ` Samuel Thibault
2003-07-12 3:09 ` Bug in open() function (?) J.C. Wren
2003-07-12 3:38 ` Andrew Morton
2003-07-12 5:11 ` Valdis.Kletnieks
2003-07-12 5:23 ` Andrew Morton
2003-07-12 6:14 ` Valdis.Kletnieks
2003-07-12 9:37 ` Andries Brouwer
2003-07-12 12:04 ` jw schultz
2003-07-12 5:39 ` J.C. Wren
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='008f01c34c38$9be3c120$c100a8c0@wakatipu' \
--to=mtk-lists@jambit.com \
--cc=aebr@win.tue.nl \
--cc=linux-kernel@vger.kernel.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).