Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Jul 2013 02:30:46 +1000
From:      Chris Johns <chrisj@rtems.org>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        freebsd-standards@FreeBSD.org
Subject:   Re: truncate and open(O_TRUNC) times.
Message-ID:  <51F698B6.7050109@rtems.org>
In-Reply-To: <20130730011126.V2176@besplex.bde.org>
References:  <51F5813D.2030806@rtems.org> <20130729191944.M928@besplex.bde.org> <20130729140654.GO4972@kib.kiev.ua> <20130730011126.V2176@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
>
> I just checked some details for another bug involving [f]truncate() and
> the file size limit. They are specified to act the same (SIGFXSZ with
> no change in the file) above the limit, but for most file systems including
> ffs, neither checks. So the flag isn't needed to fix this bug. It is
> write() that acts differently. It is specified to write up to the limit
> and then return a short write with no SIGXFXSZ if the file pointer is
> initially before the limit; otherwise SIGFXSZ with no change to the file
> (or file times?). But for most file systems including ffs, write() fails
> with SIGFXSZ and no change in the file if the result of a full successful
> write would be above the limit. This is mostly a bug in POSIX. It makes
> short write()s possible for any write(), where users can easily arrange
> for foot shooting using their soft rlimit, but almost no applications
> understand short writes.

Applications running on RTEMS with its limited resources need to know 
this and we have a test to make sure this is handled correctly by all 
file systems.

Chris



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51F698B6.7050109>