Re: kern/60807: inconsistent reporting of absent birthtime

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60807; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/60807: inconsistent reporting of absent birthtime
Date: Sun, 27 Sep 2026 04:49:26 +0700

     Date:        Sat, 26 Sep 2026 21:10:00 +0000 (UTC)
     From:        "campbell+netbsd%mumble.net@localhost via gnats" <gnats-admin%NetBSD.org@localhost>
     Message-ID:  <20260926211000.A330E1A923F%mollari.NetBSD.org@localhost>
 
   | 	File systems that don't support birthtime report it
   | 	inconsistently.  They should report it consistently, but how?
 
 Who cares, it is a waste of space and time.
 
   | 	- FreeBSD seems to use {-1,0}, which is unappealing because
   | 	  that just means 1969-01-01T23:59:59Z (proleptic UTC).
 
 1969-12-31Y23:59:59Z
 
   | 	try to write birthtime tests for other bugs
 
 Just delete birthtime ... we only ever grew this monstrosity as VMS
 had something like it, and at the time, being better than VMS at everything
 was considered important to some people.
 
 No-one has ever defined what it actually means, hence there's no way to
 use it for anything ... eg: if you copy a file onto another file (cp a b)
 where both files exist, and were previously completely unrelated,
 what should the birthtime of b be afterwards?   If the cp was rather a restore
 (tar x perhaps) (same filesystem operations) do you get the same answer?
 If the cp was a "w" command from ed (or some other editor) do you get the
 same answer?   (same filesystem operations again).
 
 We can't break the API's easily, but we can just return {0,0} for the
 birthtime of everything, always, ignore attempts to set it, etc.
 
 kre