From owner-freebsd-standards@FreeBSD.ORG Mon Jul 29 18:46:52 2013 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3CC51F13 for ; Mon, 29 Jul 2013 18:46:52 +0000 (UTC) (envelope-from chrisj@rtems.org) Received: from nskntqsrv02p.mx.bigpond.com (nskntqsrv02p.mx.bigpond.com [61.9.168.234]) by mx1.freebsd.org (Postfix) with ESMTP id C9C8B2842 for ; Mon, 29 Jul 2013 18:46:51 +0000 (UTC) Received: from nskntcmgw07p ([61.9.169.167]) by nskntmtas05p.mx.bigpond.com with ESMTP id <20130729163102.PVUN2026.nskntmtas05p.mx.bigpond.com@nskntcmgw07p>; Mon, 29 Jul 2013 16:31:02 +0000 Received: from kiwi.contemporary.net.au ([58.172.130.193]) by nskntcmgw07p with BigPond Outbound id 6GX21m0014AWQ0y01GX2qK; Mon, 29 Jul 2013 16:31:02 +0000 X-Authority-Analysis: v=2.0 cv=IccFqBWa c=1 sm=1 a=52MaS7aVRqv1DZ1aF93/eg==:17 a=rJ9FApbKPKgA:10 a=CT-yo7tBpAMA:10 a=sLc0rD4f83wA:10 a=8nJEP1OIZ-IA:10 a=DU0EyFXtAAAA:8 a=lS0MHldHvS4A:10 a=X5dPMJUElLQA:10 a=yQ0M5D1pBhB24ZYwMwAA:9 a=wPNLvfGTeEIA:10 a=52MaS7aVRqv1DZ1aF93/eg==:117 Received: from takapu.local (50-240-213-197-static.hfc.comcastbusiness.net [50.240.213.197] (may be forged)) (authenticated bits=0) by kiwi.contemporary.net.au (8.14.7/8.14.5) with ESMTP id r6TGUsr1080934 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 30 Jul 2013 02:30:55 +1000 (EST) (envelope-from chrisj@rtems.org) X-Authentication-Warning: kiwi.contemporary.net.au: Host 50-240-213-197-static.hfc.comcastbusiness.net [50.240.213.197] (may be forged) claimed to be takapu.local Message-ID: <51F698B6.7050109@rtems.org> Date: Tue, 30 Jul 2013 02:30:46 +1000 From: Chris Johns User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Bruce Evans Subject: Re: truncate and open(O_TRUNC) times. References: <51F5813D.2030806@rtems.org> <20130729191944.M928@besplex.bde.org> <20130729140654.GO4972@kib.kiev.ua> <20130730011126.V2176@besplex.bde.org> In-Reply-To: <20130730011126.V2176@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.3 required=5.0 tests=RDNS_NONE autolearn=no version=3.3.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on kiwi.contemporary.net.au Cc: freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 18:46:52 -0000 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