> Because the API requires the ability of time_t's to go negative,

Unfortunately, not all utility programs have been updated to cope with
this.  The following cautionary tale may be of some interest...

A couple of years ago, the hardware RTC on one of our Sequent machines
went beserk, and as the machine was power-cycled it started behaving
like Dr Who's Tardis, taking trips to 1955 and 2018.  This happened
when the service engineer had called to install an async card.  He carried
on installing the async card, and returned a couple of days later with
a new SSM card, after which everything seemed to be OK.

I week or two later I was duplicating the root filesystem onto the
alternate system disk using a dump | restore pipeline, when I got a
load of messages from restore "inode not on volume".  I knew that this
happened if you had deleted something after dump had scanned the
directory structure but before it had written the inode to the saveset.
However, I was fairly sure this hadn't happened because no-one else
should have been deleting anything on /.  When I repeated the
operation, I got exactly the same errors, which were all from tty
device files with modification times in 1955.  It dawned on me that
while the machine had been on its trip back in time, the engineer had
rebooted it with a -r flag, causing it to make device files for the
newly-installed async card.

We don't have source for DYNIX/ptx, but we do have source for another
(commercial) Unix.  When I looked at the source for (ufs)dump, sure
enough a level 0 dump is implemented as a dump of all files for which
mtime >= 0 || ctime >= 0.  NOT mtime >= LONG_MIN || ctime >= LONG_MIN
(which is what you'd expect if time_t is signed).  So if you ever set
the clock before 1 Jan 1970 and create or modify any files, they won't
EVER get dumped unless you touch them to a non-negative time.  I've
just had a look at the source for NetBSD dump, and it appears to have
the same problem (as presumably do all versions of dump derived from
BSD unix).  Of course no-one would set their clock to a silly time
deliberately -- would they?


Roger

------------------------------------------------------------------------------
Roger Brooks (Systems Programmer),          |  Email: R.S.Brooks@liv.ac.uk
Computing Services Dept,                    |  Tel:   +44 151 794 4441
The University of Liverpool,                |  Fax:   +44 151 794 4442
PO Box 147, Liverpool L69 3BX, UK           | 
------------------------------------------------------------------------------