From nobody Sun Oct 01 17:45:23 2023 X-Original-To: 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 4RzBM46WJQz4vbs1 for ; Sun, 1 Oct 2023 17:45:36 +0000 (UTC) (envelope-from kh@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RzBM36rqNz3bBc for ; Sun, 1 Oct 2023 17:45:35 +0000 (UTC) (envelope-from kh@panix.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=panix.com header.s=panix header.b=Zfxv9bIG; spf=pass (mx1.freebsd.org: domain of kh@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=kh@panix.com; dmarc=pass (policy=none) header.from=panix.com Received: from rain.cave (c-73-142-21-0.hsd1.ma.comcast.net [73.142.21.0]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4RzBLx0dw1z11B7 for ; Sun, 1 Oct 2023 13:45:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1696182329; bh=40hJeSj1PDKUfmNWnHj463zEIoDJvaDvKrn9xnmQVvI=; h=Date:From:To:Subject:References:In-Reply-To; b=Zfxv9bIGYf4FyTi90LccrfETuZ/QpVHKxHwbCERZQLxFSiBefJRKY0Mk1C+6t/JCW olnEihUtoD3c4ONP52/TzX51JrLWGtmo2/MGIGxxg+W06mLUcB38NcE/RBDlKAiZ3Q hgR68fCWGIVZqlxXvsCconcu9g7n8VnnWFKvEj/I= Date: Sun, 1 Oct 2023 13:45:23 -0400 From: Kurt Hackenberg To: 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; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.12 (2023-09-09) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[panix.com,none]; R_SPF_ALLOW(-0.20)[+ip4:166.84.1.64/26]; R_DKIM_ALLOW(-0.20)[panix.com:s=panix]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[166.84.1.89:from]; MLMMJ_DEST(0.00)[questions@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[panix.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[questions@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4RzBM36rqNz3bBc On Sat, Sep 30, 2023 at 06:50:29PM -0700, Edward Sanford Sutton, III wrote: > 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. Have you looked at the definition of struct stat, in /usr/include/sys/stat.h? The time members, st_mtim and such, are each a struct timespec[1], which has two members, seconds and nanoseconds. The compatibility macro st_mtime is: #define st_mtime st_mtim.tv_sec This is compatibility with old Unix and old, slow computers. I think those file times were originally only precise to a second -- they were classic Unix time, signed 32-bit seconds since 1/1/1970, UTC. Now the FreeBSD filesystem keeps those times to the nanosecond, and so needs more than 32 bits. The compatibility macro st_mtime is there for old code written when that variable was a simple integer that contained only seconds. Apparently stat(1) uses the compatibility macro, so only shows those file times to the second. That program may be old. Those times have also expanded in another way. The original Unix time, signed 32-bit seconds, will run out in the year 2038. Struct timespec's member tv_sec is of type time_t, which is 64 bits on a 64-bit machine, to greatly extend the range of Unix time. I guess people using 32-bit machines 15 years from now will be out of luck. [1] Defined in /usr/include/sys/_timespec.h