Historical Note regarding the Large File Summit:
On 10/15/2019 3:25 AM, Austin Group Bug Tracker wrote:
----------------------------------------------------------------------
(0004623) joerg (reporter) - 2019-10-15 10:25
http://austingroupbugs.net/view.php?id=1296#c4623
----------------------------------------------------------------------
If we refer to the large file summit, it may be useful to add:
EOVERFLOW
The file is a regular file and at least on of the time stamps cannot
be represented correctly in an object if type time_t
...since this has been slipped in the large file summit: The LFS struct
stat should have introduced a 64 bit time_t object as well.
When the LFS was developed (around 1991), most if not all of the
POSIX/UNIX systems had a 32-bit ABI.
The database vendors were being pressured by their customers to support
data sets that were larger than could be represented with a 32-bit
off_t. The LFS was convened to develop an extension to IEEE P1003.1
(POSIX). In order to minimize the affect on the existing UNIX ABIs, the
LFS was done as an extension that was meant to reside only on
filesystems which were explicitly formatted to support the LFS (i.e.,
LFS files would not be in the root filesystem but it could be in a
separately mounted filesystem that was reserved for databases). Since
the 64-bit off_t exists only when the user sets a compile time
directive, and that directive was not the default state of the 32-bit
compile environment, no customer application would accidentally be
compiled for the LFS.) Because the time_t is used in many more
interfaces than just the file system, and the 32-bit operating systems
returned a 32-bit time_t, for compatibility, the time_t was ruled
out-of-scope for the LFS.
The LFS was developed earlier than the events which led to the
recognition of the Year 2000 (Y2K) date problem by the general customer
base. The LFS team knew of the Y2K problem, but choose to avoid
developing a time_t change that did not have the approval of the broader
group of operating system architects on the POSIX committee. Besides,
the ABI is out-of-scope for the POSIX committee.
Side Note:
Today, most if not all POSIX/UNIX systems that support a 64-bit ABI also
support a 32-bit ABI for compatibility. All customers with 32-bit
applications who are concerned about the size of their database and the
Y2K hard stop in the year 2038 (or 2106 depending on which UNIX ABI we
are talking about) have one choice, migrate to the 64-bit ABI. When I
retired, this was the official position of most if not all of the
marketing departments of HP, IBM, Oracle, Sun etc. There are only 19
years left and times a waistin'.
Cheers,
Larry
PS: I did not log into the Bug Tracker to post this because I don't
remember what my login is, or if my login is still active, of if I ever
had a login. "And fourth, I don't have a dog" (Ref: "Racehorse" Haynes)
