Ist irgendeine Version von OS X/macOS anfällig für das Jahr-2038-Problem?

Alle Versionen vor OS X 10.6 „Snow Leopard“ haben das Jahr 2038 Problem. Die meisten Installationen von 10.6 und alle Installationen von 10.7 „Lion“ haben die Hauptursache des Problems behoben. Es ist fast weg, aber der Jahr-2038-Bug könnte in einigen Apps überleben.

Auf meinem alten PowerPC-Mac läuft OS X 10.4.11 "Tiger". Ich bin in den Systemeinstellungen zu Datum & Uhrzeit gegangen und habe versucht, ein Datum nach 2038 einzugeben, aber es hat das Datum auf den 31. Dezember 2037 zurückgesetzt. Es weiß, dass 2038 etwas nicht stimmt.

OS X wird über BSD von Unix abgeleitet. Apps für OS X verwenden BSD-Systemaufrufe für Dinge wie das Öffnen von Dateien und das Herstellen einer Internetverbindung. BSD hat eine lange Geschichte und einige seiner Systemaufrufe stammen aus den 1980er Jahren. Einer seiner Systemaufrufe ist gettimeofday(), der erstmals in 4.1cBSD auftauchte. UC Berkeley veröffentlichte 4.1cBSD im Jahr 1982 , mehr als ein halbes Jahrhundert vor 2038. Die Zeit von gettimeofday()ist eine Ganzzahl vom Typ time_t. Es zählt Sekunden, wobei Null die Unix-Epoche 1970-01-01 00:00:00 UTC ist.

In meinem alten PowerPC-Mac time_tist das eine vorzeichenbehaftete 32-Bit-Ganzzahl. Dies verursacht das Problem mit dem Jahr 2038. Eine signierte 32-Bit-Datei time_that einen Bereich von -2147483648 bis 2147483647. Dies kann nur Zeiten von 1901-12-13 20:45:52 UTC bis 2038-01-19 03:14:07 UTC enthalten. Wenn diese überläuft, wird das Datum von Montag, den 19. Januar 2038 auf Freitag, den 13.gettimeofday() Dezember 1901 umgedreht .

time_tDie Lösung besteht darin, von 32-Bit auf 64-Bit umzustellen time_t. Für OS X geschah dieser Übergang zusammen mit einem weiteren Übergang von 32-Bit-Zeigern zu 64-Bit-Zeigern, aber 64-Bit-Zeiger erfordern einen 64-Bit-Prozessor. Apple hat 64-Bit nur time_tfür 64-Bit-Prozessoren bereitgestellt. Es ist möglich, dass 32-Bit-Prozessoren 64-Bit verarbeiten time_t, aber Apple hat diese Funktion nie bereitgestellt.

Die Compiler von Apple unterstützen 64-Bit-Ganzzahlen auf 32-Bit-Prozessoren seit OS X 10.0 „Cheetah“, als es time_t32 Bit und off_t64 Bit hatte. In Unix und BSD off_tist dies die Größe einer Datei oder einer ganzen Festplatte. Eine 32-Bit-Version off_twürde OS X auf Festplatten unter 2 GiB beschränken. Apple definierte off_t64 Bit, daher funktionierte OS X mit größeren Festplatten. Apple hat in 10.0 32 Bit definiert , daher musste später time_tauf 64 Bit umgestellt werden .time_t

Für meinen alten PowerPC-Mac <ppc/_types.h>definiert die Header-Datei __darwin_time_tals long. Für Intel Mac <i386/_types.h>macht der Header dasselbe. Hat in OS X longdie gleiche Größe wie ein Zeiger. Als also Zeiger zu 64 Bit wurden, longwurden sie auch zu 64 Bit und time_twurden auch zu 64 Bit, wodurch die Hauptursache des Problems mit dem Jahr 2038 behoben wurde.

Apples 64-Bit Transition Guide sagt: „Vor OS X v10.6 waren alle Anwendungen, die mit dem Betriebssystem geliefert wurden, 32-Bit-Anwendungen. Ab Version 10.6 sind Anwendungen, die mit dem Betriebssystem geliefert werden, im Allgemeinen 64-Bit-Anwendungen ." Ich weiß aus Wikipedia , dass 10.6 einen Intel-Prozessor und 10.7 einen 64-Bit-Intel-Prozessor erforderte. Ein Mac mit 10.6 auf einem 32-Bit-Intel-Prozessor muss über 32-Bit-Apps verfügen. Ich komme zu dem Schluss, dass die meisten Macs mit 10.6 und alle Macs mit 10.7 64-Bit-Apps mit 64-Bit-Zeigern und 64-Bit- time_t. Apple veröffentlichte 10.7 im Jahr 2011, lange vor Januar 2038.

Mit 64-Bit time_tist der Jahr-2038-Bug fast verschwunden, aber er könnte in einigen Apps überleben. Alte 32-Bit-Apps können möglicherweise noch auf neueren Systemen ausgeführt werden. Außerdem können 64-Bit-Apps Programmierfehler oder veraltete Designs enthalten, was dazu führt, dass sie 64-Bit in 32-Bit konvertieren time_t. Dies ist ein Problem für alle Systeme, nicht nur für macOS.

Es gibt auch Mach-Zeit. Der Kernel von OS X mischt BSD mit Mach. Die meisten Apps erhalten die Zeit von BSD mit gettimeofday(), aber es gibt eine Möglichkeit, BSD zu umgehen und die Zeit von Mach zu erhalten. Dies ist schwieriger: Das Programm würde aufrufen mach_host_self(), um den Host-Port zu erhalten, dann , host_get_clock_service()um die CALENDAR_CLOCK, und schließlich clock_get_time().

In meinem alten Mac mit 10.4 "Tiger" <mach/clock_types.h>wird die Zeit als unsigned int(innerhalb struct mach_timespec) deklariert. Dies ist eine vorzeichenlose 32-Bit-Ganzzahl mit einem Bereich von 0 bis 4294967295, der vom 1970-01-01 00:00:00 UTC bis zum 2106-02-07 06:28:15 UTC reicht. Dies würde das Jahr-2038-Problem gegen das Jahr-2106-Problem austauschen. Es kann das Jahr 29.940 nicht erreichen.

Ich vermute, dass das host_get_clock_service()seit 10.0 "Cheetah" veraltet war, weil Apple schnellere Möglichkeiten bot, die Zeit zu bekommen. Dies waren BSDs gettimeofday()für Kalenderzeit und Apples mach_absolute_time()für monotone Zeit. Die Präferenz für gettimeofday()brachte das Problem ins Jahr 2038, nicht ins Jahr 2106.

Nun, was El Capitan 10.11.6 betrifft, ist die Antwort nicht so einfach wie die Verwendung von Perl-Skript.

Wenn wir das versuchen

macmladen@buk $ touch -t 205012121212 my
macmladen@buk $ ls -al
total 104
drwx------  7 root root    4096 Dec 25 13:42 .
drwxr-xr-x 23 root root    4096 Dec  4 17:06 ..
-rw-r--r--  1 root root       0 Dec 12  2050 my

Das beweist also , dass macOS in der niedrigsten Systemschicht vor dem Y2038-Fehler sicher ist . Das bedeutet, dass das System als solches nicht ausfällt und ordnungsgemäß funktioniert.

Auf Anwendungsebene ist dies jedoch nicht immer der Fall.

Beim Versuch, das Datum auf 2040 zu verschieben, reagierten die Systemeinstellungen Datum und Uhrzeit mit der Einstellung auf 01.01.2038 (Sie müssen die automatische Einstellung deaktivieren).

Das bedeutet, dass es von der Anwendung abhängt, wie sie auf den Y2038-Fehler reagieren.

El Capitan ist nicht anfällig:

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++)
{
print ctime($clock);
}

Dieses Perl-Skript liefert die folgende Ausgabe:

Family-iMac:~ dude$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.11.6
BuildVersion:   15G1004
Family-iMac:~ dude$ /Users/dude/Desktop/2038.pl 
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

Von dieser sehr interessanten Seite wurden Informationen zusammengetragen und Skripte zu nackten Knochen verdichtet .