OS X / macOS'un herhangi bir sürümü, 2038 Yılı sorununa açık mı?

2000 yılı civarında, Apple 1984'ten beri her Mac'in Y2K sorununu önleyeceği ve gelecek birkaç bin yıl için tarihleri ​​işleme koyabileceği bir basın açıklaması yaptı .

İyi haber şu ki, 1984'teki tanıtımlarından bu yana, Macintosh bilgisayarları 2000 yılına geçiş yapabiliyorlardı. Aslında, Mac OS ve birçok Mac uygulaması dahili olarak oluşturulmuş tarihleri ​​29.940 yılına kadar doğru bir şekilde yapabilir.

Bu ifade Mac OS 9'un en yeni işletim sistemi olduğu zaman yapıldı.

O zamandan beri, OS X (şimdi macOS olarak adlandırılır), Unix'ten türetilen baskın işletim sistemidir. Bu, herhangi bir sürümün Unix benzeri sistemleri etkileyen Y2K sorunuyla karşılaştırılabilir bir sorun olan 2038 Yılı sorununa açık olduğu anlamına mı geliyor ? Yoksa Apple’ın 29.940’la uyumlu olduğu hakkında verdiği ifade hala geçerli mi?

OS X 10.6 "Snow Leopard" dan önceki tüm sürümlerde 2038 yılı sorunu var. Çoğu 10.6 yüklemesi ve 10.7 "Aslan" ın tüm yüklemeleri sorunun asıl nedenini düzeltti. Neredeyse bitti, ancak 2038 böceği bir kaç uygulamada hayatta kalabilir.

Eski PowerPC Mac'im OS X 10.4.11 "Tiger" kullanıyor. Sistem Tercihleri'nde Tarih ve Saat’e gittim ve 2038’den sonra bir tarih girmeye çalıştım, ancak tarihi 31 Aralık 2037’ye getirdi. 2038’de bir şeyin yanlış olduğunu biliyor.

OS X, Unix'ten BSD yoluyla türetilmiştir. OS X için Uygulamalar BSD sistemini kullanır; dosya açmak ve internete bağlanmak gibi şeyleri gerektirir. BSD'nin uzun bir geçmişi var ve bazı sistem çağrıları 1980'lerden geliyor. Sistem çağrılarından biri gettimeofday(), ilk olarak 4.1cBSD'de görünen durumdur. UC Berkeley 1982 yılında 4.1cBSD yayımlanan dan 2038 öncesinde zaman daha yarım yüzyıldan gettimeofday()türünde bir tam sayıdır time_t. Sıfırın, 1970-01-01 00:00:00 UTC'deki Unix dönemi olduğu zamanları sayar.

Eski PowerPC Mac'imde, time_timzalı bir 32 bit tam sayı. Bu, 2038 yılına neden olur. İmzalı bir 32-bit time_t, -2147483648 - 2147483647 arasındadır. Bu süreleri yalnızca 1901-12-13 20:45:52 UTC - 2038-01-19 03:14:07 UTC arasında tutabilir. Bu durum aşıldığında, gettimeofday()19 Ocak 2038 Pazartesi ile 13 Aralık 1901 Cuma tarihleri ​​arasındaki tarihi değiştirecek.

Düzeltme 32-bit'ten time_t64-bit'e geçiş yapmaktır time_t. OS X için bu geçiş, 32 bit işaretçilerden 64 bit işaretçilere başka bir geçişle birlikte gerçekleşti, ancak 64 bit işaretçiler için 64 bit işlemci gerekir. Apple, time_t64 bit işlemciler için yalnızca 64 bit sağlamıştır. 32 bit işlemcilerin 64 bit işlemesi mümkündür time_t, ancak Apple bu özelliği hiç vermedi.

Apple'ın derleyicileri, 32 bit işlemci time_tve off_t64 bit olduğundan, OS X 10.0 "Çita" dan beri 32 bit işlemcilerde 64 bit tam sayıları destekledi . Unix ve BSD'de, off_tbir dosyanın boyutu veya bir diskin tamamıdır. 32 bit off_t, OS X'i 2 GiB altındaki disklerle sınırlar. Apple off_t64 bit olarak tanımlandı , bu yüzden OS X daha büyük disklerle çalıştı. Apple time_t, 10.0'da 32 bit olarak tanımlandı , bu nedenle time_tdaha sonra gerçekleşmesi için 64 bit'e geçiş gerekiyordu.

Benim eski PowerPC Mac için, üstbilgi dosyası <ppc/_types.h>tanımlar __darwin_time_tolarak long. Intel Mac için başlık <i386/_types.h>aynı şeyi yapar. OS X'te, longişaretçiyle aynı boyda. Böylece, işaretçiler 64 bit olduğunda, longaynı zamanda 64 bit time_toldu ve ayrıca 2038 sorunun asıl nedenini düzelten 64 bit oldu.

Apple'ın 64-Bit Geçiş Kılavuzu "OS X v10.6'dan önce, işletim sistemiyle birlikte gelen tüm uygulamalar 32 bit uygulamalardır. V10.6'dan başlayarak, işletim sistemiyle birlikte gelen uygulamalar genellikle 64 bit uygulamalardır ." Wikipedia'dan 10.6'nın bir Intel işlemci ve 10.7'nin 64 bit Intel işlemci gerektirdiğini biliyorum . 32 bit Intel işlemcide 10.6 çalışan bir Mac 32 bit uygulamalara sahip olmalı. 10.6 çalışan Mac'lerin çoğunun ve 10.7 çalışan tüm Mac'lerin 64-bit işaretçilerle ve 64-bit ile 64-bit uygulamaları olduğu sonucuna varıyorum time_t. Apple 2011'de 10.7'yi Ocak 2038'den önce yayımladı.

64-bit ile time_t, 2038 yılı yılı neredeyse tükenmekle birlikte birkaç uygulamada hayatta kalabilir. Eski 32 bit uygulamalar hala daha yeni sistemlerde çalışabilir. Ayrıca, 64 bit uygulamalar kodlama hataları veya eski tasarımları içerebilir, bu da 64 bit'i time_t32 bit'e dönüştürür . Bu sadece macOS için değil, tüm sistemler için bir sorundur.

Mach zamanı da var. OS X'in çekirdeği BSD'yi Mach. Çoğu uygulama BSD'den zaman alıyor gettimeofday(), ancak BSD'de dolaşmanın ve Mach'tan zaman ayırmanın bir yolu var. Bu daha zordur: program mach_host_self()ana bilgisayar portunu almak için çağırır , sonra host_get_clock_service()almak için CALENDAR_CLOCKve sonunda clock_get_time().

Eski Mac'imde 10.4 çalışan "Tiger", <mach/clock_types.h>zamanı bir unsigned int(iç struct mach_timespec) olarak ilan ediyor . Bu, 0 - 4294967295 aralığında, 1970-01-01 00:00:00 UTC - 2106-02-07 06:28:15 UTC arasında olan, işaretsiz bir 32 bit tam sayıdır. Bu, 2038 yılını 2106 yılını değiştirecek. 29.940 yılına ulaşamaz.

Bunun host_get_clock_service(), 10.0 "Çita" dan beri kullanılmayacağından şüpheliyim , çünkü Apple zaman kazanmak için daha hızlı yollar sağladı. Bunlar gettimeofday()takvim zamanı mach_absolute_time()için BSD'ler ve monotonik zaman için Apple idi . gettimeofday()Sorunu tercih etme sorunu 206'da, 2106'da değil.

El Capitan duyarlı değildir:

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

Bu perl betiği aşağıdaki çıktıyı sağlar:

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

Bilgi derlendi ve senaryo bu çok ilginç siteden kemikleri çıplak olarak sıkıştırdı .

Eh, El Capitan 10.11.6 söz konusu olduğunda, cevap Perl betiğini kullanmak kadar kolay değildir.

Bunu denersek

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

Kanıtlamaktadır Yani MacOS düşük içinde, sistem katmanı güvenlidir Y2038 böcekten elde. Bu gibi sistem anlamına gelir değil başarısız ve düzgün çalışacaktır.

Ancak, uygulama düzeyinde, her zaman böyle değildir.

Tarihi 2040'a itmeye çalışan Sistem tercihleri Tarih ve Saat, 01.01.2038 olarak ayarlayarak yanıt verdi (otomatik olarak ayarının işaretini kaldırmanız gerekecek)

Bu, uygulamanın Y2038 böceğine nasıl tepki vereceklerine bağlı olduğunu gösterir.