Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Aug 1998 00:49:07 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        joelh@gnu.org
Cc:        drosih@rpi.edu, peter.jeremy@auss2.alcatel.com.au, hackers@FreeBSD.ORG
Subject:   Re: proposal to not change time_t
Message-ID:  <199808200049.RAA00422@usr05.primenet.com>
In-Reply-To: <199808192249.RAA14808@detlev.UUCP> from "Joel Ray Holveck" at Aug 19, 98 05:49:42 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > I do think it's useful to have time resolution be better than 1
> > second.
> 
> I still haven't heard why this is a useful filesystem addition.
> (Please no flame wars!)

If your system is fast enough to compile a source file and then
replace that file with a derived source file in under a second,
then you could have a stale object file.

Another scenario is when you create a file and someone changes
the contents on you in under a second, then you believe the
timestamp (this scenario ignores the fact that you don't get
"stat+close" behaviour from close, and therefore can't know
that the timestamp is different anyway).

This basically gets into the rationale of file timestamps with
regard to "SHALL be updated" vs. "SHALL be marked for update",
which is basically in the standard for the VMS record based FS
"this is the way it currently works" lawyers.

To understand this argument vis-a-vis computers fast enough to
complete operations protected by rationale requires that you
read the standard in great gory detail.


After that's done, note that a directory is not required to be
implemented as a file, and that there is nothing prohibiting
obtaining directory information via ioctl or fcntl instead of
getdents, and that the timestamps on directories can pretty
much be ignored at the implementors discretion.  8-).

For a real gas, note that MS DOS FS's don't have seperate file
and metadata modification times (only a create time) and thus
a FAT/VFAT/VFAT32 FS is only POSIX compliant if it is mounted
read-only.  8-).


In any case, the fear was (apparently) that machines were getting
so fast that a single second resoloution was insufficient to make
POSIX guarantees, not that BSD is POSIX compliant...


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



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