From nobody Sun Oct 01 17:49:20 2023 X-Original-To: freebsd-questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RzBSQ5cFSz4vbp0 for ; Sun, 1 Oct 2023 17:50:14 +0000 (UTC) (envelope-from naddy@mips.inka.de) Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RzBSQ3ylCz3cK9 for ; Sun, 1 Oct 2023 17:50:14 +0000 (UTC) (envelope-from naddy@mips.inka.de) Authentication-Results: mx1.freebsd.org; none Received: from mips.inka.de (naddy@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1qn0Zw-008b2J-F9; Sun, 01 Oct 2023 19:50:04 +0200 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.17.1/8.17.1) with ESMTP id 391HnK1M049706; Sun, 1 Oct 2023 19:49:20 +0200 (CEST) (envelope-from naddy@lorvorc.mips.inka.de) Received: (from naddy@localhost) by lorvorc.mips.inka.de (8.17.1/8.17.1/Submit) id 391HnKkY049705; Sun, 1 Oct 2023 19:49:20 +0200 (CEST) (envelope-from naddy) Date: Sun, 1 Oct 2023 19:49:20 +0200 From: Christian Weisgerber To: "\"Edward Sanford Sutton, III\"" Cc: freebsd-questions@freebsd.org Subject: Re: st_* variables of ctim vs ctime vs ctimespec; is there a history & recommended use? Message-ID: References: List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:202113, ipnet:2a04:c9c0::/29, country:DE] X-Rspamd-Queue-Id: 4RzBSQ3ylCz3cK9 "Edward Sanford Sutton, III": > After recently finding stat(1) EXAMPLES error (I filed under PR274189 with > patch and reasoning), I was trying to learn the meanings of these variables > which lead me through reading stat(2) (found by `man lstat`) which says it > uses st_mtim and provides both st_mtime and st_mtimespec for compatibility. > I didn't find any listed reason for the compatibility otherwise and > wondered if that is documented somewhere. Historically, in old Unix and POSIX, struct stat had fields st_mtime etc. that were of type time_t and held a timestamp accurate to one second. At some point, computers got sufficiently fast that several things could happen inside a single second, and higher precision timestamps became desirable. st_mtimespec etc. was added as a non-standard BSD extension. (Also, filesystems were changed to record such timestamps in the first place.) Eventually, POSIX recognized the need for higher precision timestamps and standardized st_mtim etc. "Compatibility" is about source-code compatibility with older code bases. -- Christian "naddy" Weisgerber naddy@mips.inka.de