Date: Thu, 1 Jun 2006 23:59:42 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Scott Long <scottl@samsco.org> Cc: Maxim Konovalov <maxim@freebsd.org>, cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/ufs/ufs ufs_vnops.c Message-ID: <20060601232412.F34374@delplex.bde.org> In-Reply-To: <447EBA65.9000103@samsco.org> References: <200605311315.k4VDFUhD093628@repoman.freebsd.org> <447EBA65.9000103@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 1 Jun 2006, Scott Long wrote: > Maxim Konovalov wrote: > >> maxim 2006-05-31 13:15:29 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/ufs/ufs ufs_vnops.c Log: >> o According to POSIX, the result of ftruncate(2) is unspecified >> for file types other than VREG, VDIR and shared memory objects. >> We already handle VREG, VLNK and VDIR cases. Silently ignore >> truncate requests for all the rest. Adjust comments. > ... > If POSIX says that the result is undefined, wouldn't it be in our > best interests to return EBADF instead of 0? Or would that break > 3rd party software? POSIX says that the result is unspecified, not that it is undefined. truncate.2 has many bugs, but null changes to it are required to be (almost) consistent with this commit. This commit just makes the code agree with the documentation in one case. truncate.2 never documented that [f]truncate() panics on fifos. It tries to say that [f]truncate() always succeeds on fifos, but gets this wrong for truncate() on fifos (and device files...) residing on r/o file systems (unless we interpret fifos as not residing on file systems at all). It doesn't document that file systems cloned from ffs still panic for [f]truncate() on fifos, or the details of the panics; nor should it. See another reply for more details. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060601232412.F34374>