.DS_Store की उत्पत्ति (2006)

 (arno.org)
3 पॉइंट द्वारा GN⁺ 2024-07-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • .DS_Store 1999 में Mac OS X के लिए Finder को दोबारा बनाते समय बने Desktop Services Store का संक्षिप्त रूप है
  • उस समय Finder का codebase लगभग 8 साल पुराना था, इसलिए छोटे बदलावों में भी बहुत लागत लगती थी और असंबंधित दिखने वाले फीचर टूट जाते थे, इसलिए पूरी तरह से फिर से लिखना ज़रूरी था
  • नए Finder ने user interface और backend को अलग किया, और backend ने file enumeration, change monitoring, icon position और folder settings जैसे metadata को संभाला
  • Finder backend, Finder के बाहर भी इस्तेमाल होने वाला एक संभावित public API बना, और Finder का नाम “Desktop” करने की योजना के साथ मिलकर इसे Desktop Services नाम मिला
  • .DS_Store मूल रूप से केवल view settings या icon position बदलने पर बनना चाहिए था, लेकिन bug की वजह से अक्सर सिर्फ folder पर जाने भर से भी बन जाता है

Desktop Services Store नाम की उत्पत्ति

  • 1999 में Apple में Mac OS X Finder को नया बनाते समय पुराना Finder codebase लगभग 8 साल पुराना था
    • बदलावों के लिए बहुत बड़ा engineering effort चाहिए होता था
    • बदलाव आमतौर पर 2-3 ऐसे फीचर तोड़ देते थे जो दिखने में असंबंधित लगते थे
    • Mac OS X के लिए Finder को शुरू से फिर से लिखने का फैसला किया गया
  • rewrite प्रक्रिया में Finder के user interface और मुख्य backend functionality को अलग किया गया
    • इनके internal names क्रमशः Finder_FE और Finder_BE थे
    • backend file enumeration, file system change monitoring, metadata handling, icon position, और folder settings के लिए ज़िम्मेदार था
  • Finder backend, Finder के बाहर भी उपयोगी हो सकता था, इसलिए भविष्य में इसे public API के रूप में देने की योजना बनी
    • पहले Icon Services और Navigation Services नाम तय करने के अनुभव के आधार पर Desktop Services नाम चुना गया
    • उस समय Finder का नाम “Desktop” करने का विकल्प भी विचाराधीन था
    • .DS_Store नाम “Desktop Services Store” से आया है
    • शुरू का . Unix-आधारित OS और Mac OS में इसे hidden file की तरह मानने के लिए चुना गया था

बनने की शर्तें और बाद का प्रभाव

  • नाम और अधिक वर्णनात्मक हो सकता था, लेकिन एक बार इसके व्यापक रूप से इस्तेमाल में आ जाने के बाद इसे बदलना मुश्किल हो गया
  • .DS_Store फ़ाइल मूल रूप से तभी बननी चाहिए थी जब उपयोगकर्ता folder की view settings बदलता या icon position को manually सेट करता
    • लेकिन एक bug जो ठीक नहीं किया गया, उसकी वजह से यह फ़ाइल ज़रूरत से ज़्यादा बनने लगी
    • वास्तव में, सिर्फ folder पर जाने भर से .DS_Store फ़ाइल बन जाना लगभग तय था
  • Finder_BE, यानी Desktop Services, Finder के बाहर भी इस्तेमाल हुआ
    • Navigation Services, यानी open/save dialog, ने भी बाद में इसका इस्तेमाल करना शुरू किया
    • Mac OS की शुरुआती releases में Navigation Services इसका उपयोग नहीं करता था
    • Desktop Services API अभी तक पूरी तरह public नहीं हुआ था

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-07-04
Hacker News की टिप्पणियाँ

  • इस फ़ाइल के अलावा भी, Mac फ़ाइल सिस्टम में fork की अवधारणा की वजह से उलझन वाले पल आए थे
    यहाँ fork का मतलब fork() नहीं था, बल्कि फ़ाइल सिस्टम के अंदर डेटा घटक और resource घटक की जोड़ी के रूप में मौजूद संरचना थी; एक को metadata और दूसरे को फ़ाइल content जैसा माना जाता था
    Unix में metadata directory block inode की तरफ़ होता था और वह फ़ाइल से uniquely बंधे format में नहीं था, इसलिए tar, cpio, zip जैसी संरचनाओं को इसे अलग से व्यक्त करना पड़ता था
    Unix पर Mac-compatible फ़ाइल सपोर्ट implement करना हो तो resource fork को first-class data की तरह संभालना पड़ता था, और स्वाभाविक तरीका था हर फ़ाइल के बगल में .file जैसी फ़ाइल रखना
    उस समय UFS के inode block में resource fork की सभी attributes map नहीं की जा सकती थीं, और उसमें icon जैसी चीज़ें भी होती थीं। ज़्यादा आधुनिक file systems में directory block structure बड़ा होता है, इसलिए वे ऐसे data को बेहतर संभाल सकते हैं

    • “एक metadata, दूसरा फ़ाइल content” कहना resource fork को समझाने के लिए सही नहीं लगता
      बल्कि इसे फ़ाइल content के दो सेट के रूप में देखना ज़्यादा सही है; एक को data और दूसरे को rsrc कहा जाता था, और disk पर दोनों बस byte streams ही थे
      हालांकि resource fork में आम तौर पर 4-byte type code और 2-byte integer ID से indexed छोटे data pieces की structure stored होती थी
      68K Mac applications code, menus, dialogs, pictures, icons, strings आदि लगभग सब कुछ resource fork में डालते थे, और पुराने Mac app को बिना conversion के PC या Unix पर copy करने पर वह खाली फ़ाइल जैसा दिखता था
      इसलिए Mac app को network पर भेजने के लिए single stream में encode करना पड़ता था, और शुरुआती दौर में BinHex .hqx या MacBinary .bin, बाद में Stuffit .sit archives इस्तेमाल होते थे
      यह structure inode में fit न होने की वजह यह है कि यह असल में पूरी एक फ़ाइल को जबरन उसमें ठूँसने जैसा था। resource fork structure में खुद 16MB limit थी, लेकिन इसे अलग data stream की तरह treat करें तो इसे जितना चाहें उतना बड़ा बनाया जा सकता था
    • मुझे याद है कि resource fork में वे चीज़ें होती थीं जिन्हें पहले ResEdit से edit किया जाता था। Icons, कई GUI resources, text और translation assets भी संभव थे
      उदाहरण के लिए Escape Velocity plugins custom resource types इस्तेमाल करते थे, और ResEdit plugin से आसानी से edit किए जा सकते थे
    • NTFS में भी Alternate Data Streams हैं, लेकिन लगता है कि उनका इस्तेमाल लगभग नहीं होता
      https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(AD...
    • कोई application कौन-से file formats खोल सकता है, या application के creator code से match होने पर कौन-सा icon इस्तेमाल करना है जैसी application metadata उस application के resource fork में stored होती थी, लेकिन file metadata resource fork में stored नहीं होती थी
      File type, creator code, lock, invisible, bozo bit आदि हमेशा file system में stored होते थे
      उदाहरण के लिए MFS disk format description देख सकते हैं: https://wiki.osdev.org/MFS#File_Directory_Blocks
    • forked data की वजह से dual-format CD/DVD बनाना काफ़ी दिलचस्प काम था। शुरुआत में यह एक तरह का workaround था, लेकिन बाद में Mac burning software ने इसे आसानी से संभाल दिया
      Mac boot DVD बनाना भी अपने आप में आसान नहीं था

  • पहले .DS_Store creation बंद करने का तरीका था, ऐसा मुझे याद है, लेकिन Apple ने उसे हटा दिया, और यह बदलाव क्यों किया यह बिल्कुल समझ नहीं आता
    आखिरकार मैंने खुद एक program तक लिखा जो पूरे file system को monitor करता था और .DS_Store बनते ही उसे delete कर देता था
    [0] https://github.com/slmjkdbtl/dskill

    • Network volumes पर इसे बंद किया जा सकता है
      defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
      https://support.apple.com/en-us/102064
      Local volumes पर इसे बंद करने का तरीका कभी था, ऐसा मुझे याद नहीं
    • Apple ने file system root में . से शुरू होने वाली files बनाना शुरू करके सच में गड़बड़ कर दी
      .DS_Store की अनुमति मिलने के बाद लगता है कि दूसरे engineers ने .fseventsd, .Spotlight-V100 जैसी चीज़ों को भी आसानी से approve कर दिया
      इन files की वजह से “polluted” file systems कितनी बार देखे हैं, पता नहीं। ज़्यादातर SD cards या USB flash drives थे, लेकिन कभी-कभी इससे कहीं ज़्यादा डरावने मामले भी थे
      आम तौर पर ऐसी स्थिति में rm -rf .DS_Store .Trashes ._.Trashes .fseventsd .Spotlight-V100 चलाता हूँ, और कुछ और write होने से पहले जल्दी से drive eject कर देता हूँ
      खासकर जब किसी खराब होती disk से data copy करना हो, तो सबसे आखिरी चीज़ जो आप चाहेंगे वह है पूरी indexing शुरू होना और disk पर writes होना
      सच में, इसके लिए settings option होना चाहिए
    • find / -name ".DS_Store" -exec rm {} \; 2>/dev/null
      इसे script में डालकर crontab में add कर दें

  • .DS_Store सचमुच एक बदकिस्मत design जैसा लगता है। इसका एक उद्देश्य है और कई workarounds भी हैं, लेकिन व्यवहार में यह उससे सामना करने वाले 99% लोगों के लिए फाइल कचरा फैलाने वाली चीज बन गया है
    user experience की finishing के लिहाज से यह Apple जैसा नहीं लगता
    मैं System 7.5, OS X और Windows साथ-साथ इस्तेमाल करते हुए बड़ा हुआ, और Mac आम तौर पर अनावश्यक files या file formats, या “computer अंदर से कैसे काम करता है” जैसी implementation details को सामने दिखाने से बचता था
    इसलिए इस file का जगह-जगह बनना Mac के बारे में मेरे mental model से बिल्कुल मेल नहीं खाता और अजीब लगता है

    • जो लोग सिर्फ Apple ecosystem के अंदर रहते हैं, वे terminal इस्तेमाल न करें तो .DS_Store file कभी नहीं देखते
      Finder अब hidden files दिखाने का विकल्प चालू होने पर भी उन्हें नहीं दिखाता
      लेकिन जब Mac से Windows users को files share की जाती हैं, तो यह सच में बहुत भद्दा दिखता है, और Mac पर switch करने के बारे में सोच रहे लोगों पर खराब पहला impression डाल सकता है
    • Apple की finish quality हमेशा अंदरूनी हिस्से से ज्यादा सतह के करीब रही है

  • समझ नहीं आता कि इसे उसी folder के अंदर क्यों होना चाहिए। क्या operating system कहीं अपनी छोटी database रखकर हर path को reference नहीं कर सकता?

    • मंशा यह थी कि file labels जैसा metadata, network drive किसी भी device से इस्तेमाल हो, उसके साथ move हो सके
    • folder के अंदर रखने का फायदा यह भी है कि folder delete होने पर यह naturally साथ में delete हो जाता है

  • मैं इस बात से सहमत हूं कि “यह तभी बनना चाहिए जब user वास्तव में view settings adjust करे या folder के अंदर icons की positions manually तय करे।” लेकिन असल में सिर्फ folder visit करने भर से .DS_Store बनना लगभग तय है
    Finder को लेकर मेरी सबसे बड़ी शिकायत यही है
    Classic Mac OS Finder की तरह individual folder windows का look और size अलग-अलग customize कर पाना सचमुच शानदार feature है
    लेकिन जब आप उसी folder को browser window के तौर पर बस पार कर जाते हैं, तो कुछ बदले बिना भी उस customization का ज्यादातर हिस्सा browser window settings से overwrite हो जाता है
    अगर यह इतनी आसानी से टूटने वाला है, तो बेहतरीन customization allow करने का मतलब ही क्या है
    मैं global shortcut से Applications folder खोलता हूं, लेकिन उस window का look सजाना चाहूं तो भी कोई फायदा नहीं। shortcut दबाने पर क्या दिखेगा, पता नहीं होता और यह बार-बार reset हो जाता है
    वजह यह है कि Finder में default browser window configuration set करने का कोई तरीका नहीं है। इसके बजाय यह हर visit किए गए folder में current browser settings छोड़ देता है, जो बहुत frustrating है

    • Darwin से पहले, एक खुले folder का मतलब एक window होता था और user भी एक ही होता था, इसलिए वह approach ठीक बैठती थी
      वही window आखिरी बार छोड़े गए look के साथ सामने आ जाती थी—यह बहुत अच्छा था और उसकी याद आती है
    • global तो नहीं, लेकिन Finder के अंदर cmd-shift-A से Applications folder खोला जा सकता है, और cmd-shift-U से Utilities folder

  • मैं Mac user नहीं हूं, इसलिए GitHub जैसी जगहों से मिले .tgz में ढेर सारे .DS_Store हों तो हमेशा थोड़ा झुंझलाहट होती है
    macOS शायद GNU tar इस्तेमाल करता है, लेकिन default रूप से .DS_Store ignore करने के लिए उसे modify या configure नहीं किया गया, यह काफी हैरानी की बात है

    • default नहीं है, लेकिन ऐसा करवाया जा सकता है
      COPYFILE_DISABLE=true export करने पर tar .DS_Store files को skip कर देता है
    • Mac की ज्यादातर Unix utilities Apple ने खास तौर पर modify नहीं की हैं, बल्कि वे लगभग सीधे FreeBSD से आई हैं

  • network volumes browse करते समय .DS_Store file creation को default रूप से बंद करने का तरीका उल्लेख करने लायक है। वरना सिर्फ Finder से browse करने भर से directory modification time बदल जाता है, और यह सच में बहुत खराब है
    https://old.reddit.com/r/MacOS/comments/lvju40/comment/gpc8i...

    • आजकल macOS चालाक हो गया है। Finder से network volume में .DS_Store है या नहीं देखा तो नहीं दिखा, लेकिन terminal में जाकर देखा तो वास्तव में था
      अब Finder के hidden files दिखाने वाले feature पर भरोसा नहीं किया जा सकता। सारी hidden files दिखाने के बजाय, Finder केवल वही hidden files दिखाता है जिन्हें वह समझता है कि user को ध्यान देना चाहिए
      मेरा network share local Synology है, इसलिए बड़ा issue नहीं है, लेकिन workplace में इन files ने काफी गंदगी पैदा की थी
    • निजी तौर पर, मैं Mac users को network share पर write permission मिलने से पहले यह setting करवाता हूं। मुझे यह सामान्य shared-use etiquette लगता है
    • अगर आप Samba चला रहे हैं, तो ऐसी creation requests को बस ignore करने के लिए Samba configuration भी की जा सकती है

  • dot underscore (._) files भी होती हैं। network share पर ऐसी files बनने से रोकने के लिए क्या उन्हें disable करने का कोई तरीका है?
    [0] https://superuser.com/questions/212896/is-there-any-way-to-p...

  • अच्छी बात है कि Emacs के file manager Dired का इस्तेमाल करें तो इस परेशान करने वाली छोटी file और LaTeX run से बनने वाली files को आसानी से ऐसे ignore किया जा सकता है जैसे वे मौजूद ही न हों
    (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\\)$")