.DS_Store’un Kökeni (2006)

 (arno.org)
3 puan yazan GN⁺ 2024-07-04 | 1 yorum | WhatsApp'ta paylaş
  • .DS_Store, 1999’da Mac OS X için Finder yeniden oluşturulurken ortaya çıkan Desktop Services Store kısaltmasıdır
  • O dönemde Finder kod tabanı yaklaşık 8 yıllıktı; küçük değişiklikler bile büyük maliyet getiriyor ve ilgisiz görünen özellikleri bozuyordu, bu yüzden baştan yeniden yazılması gerekiyordu
  • Yeni Finder, kullanıcı arayüzü ile arka ucu ayırdı; arka uç dosya listeleme, değişiklik izleme, simge konumları ve klasör ayarları gibi metaverilerden sorumluydu
  • Finder arka ucu, Finder dışında da kullanılabilecek herkese açık bir API adayı hâline geldi ve Finder’ın adının “Desktop” olarak değiştirilmesi fikriyle bağlantılı olarak Desktop Services adını aldı
  • .DS_Store aslında yalnızca görünüm ayarları veya simge konumları değiştirildiğinde oluşturulmalıydı; ancak bir hata nedeniyle çoğu zaman sadece bir klasöre girildiğinde bile oluşturuluyordu

Desktop Services Store adının doğuşu

  • 1999’da Apple’da Mac OS X Finder yeniden yapılırken mevcut Finder kod tabanı yaklaşık 8 yıllıktı
    • Değişiklikler ciddi mühendislik çabası gerektiriyordu
    • Değişiklikler genellikle ilgisiz görünen 2-3 özelliği bozuyordu
    • Mac OS X için Finder’ın sıfırdan yeniden yazılmasına karar verildi
  • Yeniden yazım sürecinde Finder’ın kullanıcı arayüzü ile temel işlev arka ucu birbirinden ayrıldı
    • İç adları sırasıyla Finder_FE ve Finder_BE idi
    • Arka uç dosya listeleme, dosya sistemi değişikliklerini izleme, metaveri işleme, simge konumları ve klasör ayarlarından sorumluydu
  • Finder arka ucu, Finder dışında da yararlı olabileceği için bir gün herkese açık API olarak sunulması planlandı
    • Daha önce Icon Services ve Navigation Services adlarını belirleme deneyimine dayanarak Desktop Services adı seçildi
    • O dönemde Finder’ın adını “Desktop” olarak değiştirme seçeneği de değerlendiriliyordu
    • .DS_Store adı “Desktop Services Store”dan gelir
    • Baştaki . Unix benzeri işletim sistemlerinde ve Mac OS’te görünmeyen dosya olarak ele alınmasını sağlamak için seçilmişti

Oluşturulma koşulları ve sonraki etkileri

  • Ad daha açıklayıcı bir biçimde seçilebilirdi, ancak yaygın olarak kullanılmaya başladıktan sonra değiştirilmesi zor hâle geldi
  • .DS_Store dosyası aslında yalnızca kullanıcı bir klasörün görünüm ayarlarını değiştirdiğinde veya simge konumlarını elle belirlediğinde oluşturulmalıydı
    • Ancak düzeltilmeyen bir hata nedeniyle dosya gereğinden fazla oluşturuldu
    • Pratikte yalnızca bir klasörü ziyaret etmek bile .DS_Store dosyasının oluşturulmasını neredeyse garanti eder hâle geldi
  • Finder_BE, yani Desktop Services, Finder dışında da kullanıldı
    • Navigation Services, yani aç/kaydet iletişim kutuları da daha sonra bunu kullanmaya başladı
    • Mac OS’in ilk sürümlerinde Navigation Services bunu kullanmıyordu
    • Desktop Services API henüz tamamen herkese açık hâle getirilmiş değil

İlgili okumalar

1 yorum

 
GN⁺ 2024-07-04
Hacker News yorumları

  • Bu dosyanın dışında, Mac dosya sistemindeki fork kavramı yüzünden kafa karıştıran anlar da olmuştu.
    Buradaki fork, fork() değil; dosya sistemi içinde veri bileşeniyle kaynak bileşeninin bir çift olarak var olduğu bir yapıydı. Biri metadata, diğeri dosya içeriği gibi ele alınıyordu.
    Unix’te metadata dizin bloklarındaki inode tarafındaydı ve dosyaya özgü biçimde bağlanmış değildi; bu yüzden tar, cpio, zip gibi yapılar bunu ayrıca ifade etmek zorundaydı.
    Unix’te Mac uyumlu dosya desteği uygulamak için resource fork’u birinci sınıf veri olarak ele almak gerekiyordu; doğal yöntem de her dosyanın yanında .file gibi bir dosya bulundurmaktı.
    O dönemde UFS’in inode bloğu resource fork’un tüm özelliklerini eşleyemiyordu; ikonlar gibi şeyler de bunun içindeydi. Daha modern dosya sistemlerinde dizin bloğu yapısı daha büyük olduğundan bu tür veriler daha iyi işlenebiliyor.

    • “Biri metadata, diğeri dosya içeriği” diye ifade etmenin resource fork’u açıklamak için doğru olmadığını düşünüyorum.
      Aslında dosya içeriğinin iki ayrı kümesi varmış gibi görmek daha doğru; biri data, diğeri rsrc olarak adlandırılıyordu ve diskte ikisi de sadece bayt akışıydı.
      Ancak resource fork genellikle 4 baytlık tür kodu ve 2 baytlık tamsayı ID ile indekslenen küçük veri parçalarından oluşan bir yapı saklıyordu.
      68K Mac uygulamaları kod, menü, iletişim kutusu, resim, ikon, metin dizeleri vb. neredeyse her şeyi resource fork’a koyuyordu; eski bir Mac uygulamasını dönüştürmeden PC’ye ya da Unix’e kopyalayınca boş dosya gibi görünüyordu.
      Bu yüzden Mac uygulamalarını ağ üzerinden göndermek için tek bir akışa kodlamak gerekiyordu; ilk dönemlerde BinHex .hqx veya MacBinary .bin, daha sonra Stuffit .sit arşivleri kullanıldı.
      Bu yapının inode’a uymamasının nedeni, fiilen bütün bir dosyayı olduğu gibi oraya tıkıştırmaya çalışmakla aynı olmasıydı. Resource fork yapısının kendisinde 16 MB sınırı vardı, ancak ayrı bir veri akışı olarak ele alınırsa istenildiği kadar büyük yapılabilirdi.
    • Resource fork’ta eskiden ResEdit ile düzenlenen şeylerin bulunduğunu hatırlıyorum. İkonlar, çeşitli GUI kaynakları, metin ve çeviri varlıkları da olabiliyordu.
      Örneğin Escape Velocity eklentileri özel kaynak türleri kullanıyordu ve ResEdit eklentisiyle kolayca düzenlenebiliyordu.
    • NTFS’te de alternatif veri akışları (Alternate Data Streams) var ama neredeyse hiç kullanılmadığını düşünüyorum.
      https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(AD...
    • Bir uygulamanın açabildiği dosya türleri ya da uygulamanın creator code’u ile eşleştiğinde hangi ikonun kullanılacağı gibi uygulama metadataları o uygulamanın resource fork’unda saklanıyordu; ancak dosya metadatası resource fork’ta saklanmıyordu.
      Dosya türü, creator code, kilit, invisible, bozo bitleri vb. her zaman dosya sisteminde saklanıyordu.
      Örneğin MFS disk biçimi açıklamasına bakılabilir: https://wiki.osdev.org/MFS#File_Directory_Blocks
    • Fork’lu veriler yüzünden çift formatlı CD/DVD yapmak epey ilginçti. Başta bir tür hileydi ama sonradan Mac yazma yazılımları bunu kolayca halleder oldu.
      Mac önyükleme DVD’si yapmak da kendi çapında hiç kolay değildi.

  • Eskiden .DS_Store oluşturmayı kapatmanın bir yolu olduğunu hatırlıyorum; Apple bunu kaldırdı ve bu değişikliği neden yaptıklarını hiç anlamıyorum.
    Sonunda tüm dosya sistemini izleyip .DS_Store oluşur oluşmaz silen bir programı kendim yazdım.
    [0] https://github.com/slmjkdbtl/dskill

    • Ağ birimlerinde kapatılabiliyor.
      defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
      https://support.apple.com/en-us/102064
      Yerel birimlerde kapatmanın bir yolu olduğunu hatırlamıyorum.
    • Apple, dosya sistemi kökünde . ile başlayan dosyalar oluşturmaya başlayarak gerçekten ortalığı berbat etti.
      .DS_Storea izin verildikten sonra diğer mühendislerin .fseventsd, .Spotlight-V100 gibi şeyleri de kolayca onaylamış olması muhtemel görünüyor.
      Bu dosyalar yüzünden kaç tane “kirlenmiş” dosya sistemi gördüğümü bilmiyorum. Çoğu SD kart ya da USB flash sürücüydü ama bazen çok daha korkunç durumlar da oluyordu.
      Genelde böyle durumlarda rm -rf .DS_Store .Trashes ._.Trashes .fseventsd .Spotlight-V100 çalıştırıp, başka bir şey yazılmadan sürücüyü hızla çıkarıyorum.
      Özellikle durumu kötüleşen bir diskten veri kopyalamak gerektiğinde, en istemeyeceğiniz şey tam indekslemenin başlaması ve diske yazma yapılmasıdır.
      Cidden, bunun için bir ayar seçeneği olmalı.
    • find / -name ".DS_Store" -exec rm {} \; 2>/dev/null
      Bunu bir betiğe koyup crontab’e eklemek yeterli.

  • .DS_Store gerçekten talihsiz bir tasarım gibi görünüyor. Bir amacı var ve çeşitli geçici çözümler de mevcut, ama pratikte karşılaşan insanların %99’una dosya çöpü saçan bir şeye dönüşmüş durumda.
    Kullanıcı deneyimi cilası açısından Apple’a pek yakışmıyor.
    System 7.5, OS X ve Windows’u birlikte kullanarak büyüdüm; Mac, gereksiz dosyaları ya da dosya biçimlerini, “bilgisayarın içeride nasıl çalıştığı” gibi uygulama ayrıntılarını kullanıcıya özellikle göstermezdi.
    Bu yüzden bu dosyanın her yerde oluşması, Mac’e dair zihinsel modelimle hiç uyuşmadığı için tuhaf geliyor.

    • Sadece Apple ekosistemi içinde yaşayan biri, terminal kullanmadığı sürece .DS_Store dosyalarını asla görmez.
      Finder, gizli dosyaları gösterme seçeneği açık olsa bile artık bunları göstermiyor.
      Ancak Mac’ten Windows kullanıcılarına dosya paylaşırken gerçekten çirkin görünüyor ve Mac’e geçmeyi düşünen birine kötü bir ilk izlenim verebileceğini düşünüyorum.
    • Apple’ın bitirme kalitesi her zaman içeriden çok yüzeye daha yakındı.

  • Neden aynı klasörün içinde olmak zorunda olduğunu anlamıyorum. İşletim sistemi bir yerde kendi küçük veritabanını tutup her yolu ona göre referans alamaz mı?

    • Amaç, dosya etiketleri gibi üst verilerin ağ sürücüsü hangi cihazda kullanılırsa kullanılsın birlikte taşınmasını sağlamaktı.
    • Klasörün içinde tutmanın, klasör silindiğinde doğal olarak onunla birlikte silinmesi gibi bir avantajı da var.

  • “Yalnızca kullanıcı görünüm ayarlarını gerçekten değiştirdiğinde ya da klasör içindeki simge konumlarını elle belirlediğinde oluşturulmalı” görüşüne katılıyorum. Ama gerçekte, sadece bir klasörü ziyaret etmek bile .DS_Store oluşturulmasını neredeyse garanti ediyor.
    Finder’daki en büyük şikâyetim bu.
    Classic Mac OS Finder’daki gibi tek tek klasör pencerelerinin görünümünü ve boyutunu çok çeşitli biçimlerde özelleştirebilmek gerçekten harika bir özellik.
    Ama aynı klasörden sadece bir tarayıcı penceresiyle geçseniz bile, hiçbir şeyi değiştirmediğiniz hâlde bu özelleştirmelerin çoğu tarayıcı penceresi ayarlarıyla eziliyor.
    Bu kadar kolay bozulacaksa harika özelleştirmelere izin vermenin anlamı yok.
    Applications klasörünü global bir kısayolla açıyorum; o pencerenin görünümünü süslemek istesem de faydası yok. Kısayola her bastığımda ne göreceğimi bilemiyorum ve sürekli sıfırlanıyor.
    Bunun nedeni Finder’da varsayılan tarayıcı penceresi düzenini ayarlamanın bir yolu olmaması. Bunun yerine ziyaret edilen her klasöre mevcut tarayıcı ayarlarını bırakıyor; gerçekten sinir bozucu.

    • Darwin’den önce açık bir klasör bir pencereye karşılık geliyordu ve tek kullanıcı vardı; bu yüzden o yaklaşım gayet iyi işliyordu.
      Aynı pencerenin en son bıraktığım hâliyle öne fırlamasını çok severdim; özlüyorum.
    • Global değil ama Finder içinde cmd-shift-A ile Applications klasörünü, cmd-shift-U ile Utilities klasörünü açabilirsiniz.

  • Mac kullanıcısı olmadığım için, GitHub gibi yerlerden aldığım .tgz dosyalarının içinde bir sürü .DS_Store olduğunda hep biraz sinirleniyorum.
    macOS muhtemelen GNU tar kullanıyor gibi, ama varsayılan olarak .DS_Store dosyalarını yok sayacak şekilde yamalanmamış ya da yapılandırılmamış olması epey şaşırtıcı.

    • Varsayılan değil, ama bunu yapacak hâle getirilebilir.
      COPYFILE_DISABLE=true dışa aktarılırsa tar .DS_Store dosyalarını atlar.
    • Mac’teki Unix yardımcı araçlarının çoğu Apple’ın özel olarak elden geçirdiği şeyler değil; neredeyse aynen FreeBSD’den geliyor.

  • Ağ birimlerinde gezinirken .DS_Store dosyası oluşturulmasını varsayılan olarak kapatmanın yolundan bahsetmeye değer. Aksi hâlde Finder ile sadece dolaşmak bile dizin değiştirilme zamanını değiştiriyor ki bu gerçekten berbat.
    https://old.reddit.com/r/MacOS/comments/lvju40/comment/gpc8i...

    • Güncel macOS bu konuda seçici davranıyor. Finder’da bir ağ biriminde .DS_Store var mı diye baktığımda yok gibi görünüyordu, ama terminale geçtiğimde aslında var olduğunu gördüm.
      Artık Finder’ın gizli dosyaları gösterme özelliğine güvenilemiyor. Çünkü tüm gizli dosyaları göstermek yerine, yalnızca Finder’ın kullanıcının önemsemesi gerektiğine karar verdiği gizli dosyaları gösteriyor.
      Benim ağ paylaşımım yerel bir Synology olduğu için büyük sorun değil, ama iş yerinde bu dosyalar epey dağınık bir durum yaratmıştı.
    • Şahsen Mac kullanıcılarına ağ paylaşımında yazma izni verilmeden önce bu ayarı yaptırıyorum. Bunu makul bir ortak kullanım nezaketi olarak görüyorum.
    • Samba çalıştırıyorsanız, bu tür oluşturma isteklerini doğrudan yok sayacak şekilde Samba yapılandırması da yapabilirsiniz.

  • Nokta-alt çizgi (._) dosyaları da var. Ağ paylaşımlarında bu dosyaların oluşmasını engellemek için devre dışı bırakmanın bir yolu var mı?
    [0] https://superuser.com/questions/212896/is-there-any-way-to-p...

  • Neyse ki Emacs’in dosya yöneticisi Dired kullanıldığında bu sinir bozucu küçük dosyaları ve LaTeX çalıştırmanın oluşturduğu dosyaları kolayca yokmuş gibi davranabilirsiniz.
    (setq dired-omit-mode t
    dired-omit-files "^.+\\.\\(DS_Store\\|aux\\|bak\\|bbl\\|bcf\\|blg\\|dvi\\|ent\\|idx\\|ilg\\|ind\\|log\\|orig\\|out\\|pdf-view-restore\\|pdf#\\|reg\\|run.xml\\|synctex.gz\\|toc\\)$")