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>