NetBSD Problem Report #60807

From www@netbsd.org  Sat Sep 26 21:09:34 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.netbsd.org", Issuer "YR1" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id AC1F51A923C
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 26 Sep 2026 21:09:33 +0000 (UTC)
Message-Id: <20260926210932.AC9851A923E@mollari.NetBSD.org>
Date: Sat, 26 Sep 2026 21:09:32 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: inconsistent reporting of absent birthtime
X-Send-Pr-Version: www-1.0
X-From4GNATS: "campbell+netbsd@mumble.net via gnats" <gnats-admin@NetBSD.org>

>Number:         60807
>Category:       kern
>Synopsis:       inconsistent reporting of absent birthtime
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 26 21:10:00 +0000 2026
>Last-Modified:  Sat Sep 26 21:55:01 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current, 11, 10, ...
>Organization:
The FileBSD Birthdation, Inc.
>Environment:
>Description:

	File systems that don't support birthtime report it
	inconsistently.  They should report it consistently, but how?

	- Those whose VOP_GETATTR operations leave it uninitialized
	  (such as v7fs, sysvbfs) will, owing to the memset in vn_stat,
	  return {0,0}, which is to say, 1970-01-01T00:00:00Z
	  (proleptic UTC).

	- Those whose VOP_GETATTR operations use vattr_null and then
	  don't initialize va_birthtimespec will return {-1,-1}, which
	  is appealing because it is an invalid struct timespec.  nfs
	  also does this (explicitly, with VNOVAL).

	- FreeBSD seems to use {-1,0}, which is unappealing because
	  that just means 1969-01-01T23:59:59Z (proleptic UTC).

>How-To-Repeat:

	try to write birthtime tests for other bugs

>Fix:

	Yes, please!

>Audit-Trail:
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
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 via gnats" <gnats-admin@NetBSD.org>
     Message-ID:  <20260926211000.A330E1A923F@mollari.NetBSD.org>

   | 	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

Home	PR Database Search