On Tue, 25 Jul 2006 08:31:44 +0200 Roland Mainz wrote:
> I found another issue in the Solaris bug database which may (or may not)
> affect ksh93.
> Sun-Bug #6417347
> (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6417347)
> describes a problem with the "test" builtin in various shells (including
> Solaris ksh) which causes problems with the -nt/-ot operators vs. inode
> timestame accuracy.
> >From the bug's description:
> -- snip --
> solaris file timestamps are of better-than sub-second resolution; these
> higher-resolution timestamps can be displayed with ls -E, but they are
> not included in the comparisons done by test's -nt and -ot operators.
> Filing as defect rather than RFE because the documentation for "test"
> makes no reference to any limited resolution of the timestamp but merely
> refers to whether the file is older or newer.
> this appears to be common across multiple shells (ksh, zsh, bash,
> /bin/test); I'm filing against ksh first to raise awareness of this.
> as systems speed up, the chance that scripts using -nt and -ot will
> break due to same-second timestamps increases.
> -- snip --
> The question is: What is the correct behaviour in this case ? And how
> does ksh93r+ currently behave ?
hi resolution timestamps if the system supports them
if you have the ast touch:
touch -t 2006-01-20+13:08:27.604848000 a
touch -t 2006-01-20+13:08:27.604849000 b
for sh in ksh sh bash zsh
do $sh -c "test a -ot b && echo $sh: high resolution"
done
ksh93 (and ast nmake ls touch etc.) use the <tmx.h> api that converts
hi res time to unsigned 64 bit Time_t nanoseconds since the epoch
note: try this on linux and the hi res part may go to 0 once the
inode is flushed
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
