Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Jan 2006 15:24:23 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Diomidis Spinellis <dds@aueb.gr>
Cc:        cvs-src@FreeBSD.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, src-committers@FreeBSD.org, Diomidis Spinellis <dds@FreeBSD.org>, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/kern vfs_syscalls.c
Message-ID:  <20060104151121.T50198@delplex.bde.org>
In-Reply-To: <43BB0D3B.10300@aueb.gr>
References:  <88559.1136330180@critter.freebsd.dk> <43BB0D3B.10300@aueb.gr>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Jan 2006, Diomidis Spinellis wrote:

> Poul-Henning Kamp wrote:
>> In message <200601032158.k03LwMGP031138@repoman.freebsd.org>, Diomidis 
>> Spinellis writes:
>> 
>>> dds         2006-01-03 21:58:22 UTC
>>> 
>>> FreeBSD src repository
>>> 
>>> Modified files:
>>>   sys/kern             vfs_syscalls.c Log:
>>> Normalize the tv_usec part of the utimes(2) arguments to ensure
>>> that a file's atime and mtime are only set to correct fractional
>>> second values (0-999999000ns with the current interface).
>> 
>> I think this is wrong.  We should return EINVAL if the fractional
>> part is not correct.

I sent private mail saying similar things in more detail.

> I saw that one coming :-)  Solaris (SunOS 5.10) returns EINVAL, Mac OS X 
> Tiger and Linux 2.4.21 appear to ignore the field, and NetBSD 1.5 follows our 
> buggy behavior.  POSIX is silent on the matter, and does not specify EINVAL 
> in the list of prescribed errno values 
> <http://www.opengroup.org/onlinepubs/007908799/xsh/utimes.html>.

POSIX requires the error handling for many (most?) syscalls that deal
with timevals (and timespecs?), but is sloppy for utimes(), perhaps
because historical implementations are sloppy.  FreeBSD does it for
most (all?) other syscalls that deal with timevals, using mainly
itimerfix() (which is mostly about error detection but not fixing) for
timevals (including ones not related to itimers) and direct checks for
timespecs.  Direct checks take less code than calling a function to
do the checks but more code than calling a function that both checks
and "fixes".

> On the other hand, normalization is easy, relatively efficient, follows the 
> letter of the standard, and will not break existing software.  As a 
> precedent, consider that Unix traditionaly normalizes filename paths.

Normalization is not so easy if you avoid overflow and sign problems
in the normalization.

Bruce



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