จุดกำเนิดของ .DS_Store (2006)

 (arno.org)
3 คะแนน โดย GN⁺ 2024-07-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • .DS_Store เป็นตัวย่อของ Desktop Services Store ที่เกิดขึ้นระหว่างการสร้าง Finder สำหรับ Mac OS X ขึ้นใหม่ในปี 1999
  • ในเวลานั้น โค้ดเบสของ Finder มีอายุราว 8 ปี แล้ว ทำให้แม้การเปลี่ยนแปลงเล็กน้อยก็มีต้นทุนสูง และมักทำให้ฟีเจอร์ที่ดูเหมือนไม่เกี่ยวข้องพัง จึงจำเป็นต้อง เขียนใหม่ทั้งหมด
  • Finder ตัวใหม่แยกส่วนติดต่อผู้ใช้ออกจากแบ็กเอนด์ โดยแบ็กเอนด์รับผิดชอบ เมตะดาตา เช่น การไล่รายการไฟล์ การเฝ้าดูการเปลี่ยนแปลง ตำแหน่งไอคอน และการตั้งค่าโฟลเดอร์
  • แบ็กเอนด์ของ Finder กลายเป็นตัวเลือกสำหรับ public API ที่สามารถใช้นอก Finder ได้ และควบคู่ไปกับแนวคิดในการเปลี่ยนชื่อ Finder เป็น “Desktop” จึงได้ชื่อว่า Desktop Services
  • เดิมที .DS_Store ควรถูกสร้างขึ้นก็ต่อเมื่อมีการเปลี่ยนการตั้งค่ามุมมองหรือตำแหน่งไอคอนเท่านั้น แต่เพราะบั๊กจึงมักถูกสร้างขึ้นแม้เพียงแค่เข้าไปดูโฟลเดอร์

การถือกำเนิดของชื่อ Desktop Services Store

  • ในปี 1999 ตอนที่ Apple กำลังสร้าง Finder ของ Mac OS X ขึ้นใหม่ โค้ดเบส Finder เดิมมีอายุประมาณ 8 ปี แล้ว
    • การเปลี่ยนแปลงต้องใช้ความพยายามทางวิศวกรรมสูง
    • การเปลี่ยนแต่ละครั้งมักทำให้ฟีเจอร์อีก 2-3 อย่างที่ดูเหมือนไม่เกี่ยวข้องพัง
    • จึงตัดสินใจเขียน Finder สำหรับ Mac OS X ขึ้นใหม่ตั้งแต่ต้น
  • ระหว่างการเขียนใหม่ ได้แยก ส่วนติดต่อผู้ใช้ ของ Finder ออกจาก แบ็กเอนด์ฟังก์ชันหลัก
    • ชื่อภายในคือ Finder_FE และ Finder_BE ตามลำดับ
    • แบ็กเอนด์รับผิดชอบการไล่รายการไฟล์ การเฝ้าดูการเปลี่ยนแปลงของระบบไฟล์ การจัดการเมตะดาตา ตำแหน่งไอคอน และการตั้งค่าโฟลเดอร์
  • แบ็กเอนด์ของ Finder อาจมีประโยชน์นอก Finder ด้วย จึงเกิดแผนว่าจะเปิดให้ใช้เป็น public API ในอนาคต
    • จากประสบการณ์ที่เคยตั้งชื่อ Icon Services และ Navigation Services มาก่อน จึงเลือกชื่อว่า Desktop Services
    • ในเวลานั้นยังมีการพิจารณาแนวคิดในการเปลี่ยนชื่อ Finder เป็น “Desktop” อยู่ด้วย
    • .DS_Store มาจากชื่อ “Desktop Services Store”
    • เครื่องหมาย . ด้านหน้าเป็นการเลือกเพื่อให้ระบบปฏิบัติการตระกูล Unix และ Mac OS มองว่าเป็นไฟล์ที่ซ่อนไว้

เงื่อนไขการสร้างและผลกระทบในภายหลัง

  • ชื่อนี้อาจถูกตั้งให้สื่อความหมายมากกว่านี้ได้ แต่หลังจากถูกใช้อย่างแพร่หลายแล้วก็เปลี่ยนได้ยาก
  • เดิมไฟล์ .DS_Store ควรถูกสร้างขึ้นเฉพาะเมื่อผู้ใช้ปรับการตั้งค่ามุมมองของโฟลเดอร์ หรือกำหนดตำแหน่งไอคอนด้วยตนเองเท่านั้น
    • แต่เพราะบั๊กที่ไม่เคยถูกแก้ไข ไฟล์จึงถูกสร้างมากเกินไป
    • ในทางปฏิบัติ แทบจะรับประกันได้เลยว่าเพียงแค่เข้าไปดูโฟลเดอร์ก็จะมีการสร้างไฟล์ .DS_Store
  • Finder_BE หรือ Desktop Services ถูกนำไปใช้นอก Finder ด้วย
    • Navigation Services หรือกล่องโต้ตอบเปิด/บันทึก ก็หันมาใช้สิ่งนี้ในภายหลัง
    • ในรีลีสแรก ๆ ของ Mac OS นั้น Navigation Services ยังไม่ได้ใช้สิ่งนี้
    • Desktop Services API ยังไม่ได้ถูกเปิดเผยอย่างสมบูรณ์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-04
ความคิดเห็นจาก Hacker News

  • นอกจากไฟล์นี้แล้ว ยังเคยมีช่วงที่สับสนเพราะแนวคิดเรื่อง fork ในระบบไฟล์ของ Mac
    fork ในที่นี้ไม่ใช่ fork() แต่เป็นโครงสร้างในระบบไฟล์ที่มีองค์ประกอบข้อมูลกับองค์ประกอบทรัพยากรอยู่เป็นคู่กัน โดยอันหนึ่งถูก扱เสมือนเมทาดาทา อีกอันถูก扱เสมือนเนื้อหาไฟล์
    บน Unix เมทาดาทาอยู่ฝั่ง inode ของบล็อกไดเรกทอรี และไม่ได้เป็นรูปแบบที่ผูกกับไฟล์แบบเฉพาะตัว ดังนั้นโครงสร้างอย่าง tar, cpio, zip จึงต้องแสดงมันแยกต่างหาก
    หากจะทำระบบรองรับไฟล์ที่เข้ากันได้กับ Mac บน Unix ก็ต้อง扱 resource fork เป็นข้อมูลชั้นหนึ่ง และวิธีที่เป็นธรรมชาติคือวางไฟล์อย่าง .file ไว้ข้าง ๆ แต่ละไฟล์
    ในตอนนั้นบล็อก inode ของ UFS ไม่สามารถแมปคุณสมบัติทั้งหมดของ resource fork ได้ และในนั้นยังมีอย่างไอคอนด้วย ระบบไฟล์ที่ทันสมัยกว่านั้นมีโครงสร้างบล็อกไดเรกทอรีที่ใหญ่กว่า จึงจัดการข้อมูลแบบนี้ได้ดีกว่า

    • ผมคิดว่าการอธิบายว่า “อันหนึ่งเป็นเมทาดาทา อีกอันเป็นเนื้อหาไฟล์” นั้นไม่แม่นยำสำหรับการอธิบาย resource fork
      ควรมองว่ามีเนื้อหาไฟล์อยู่สองชุดมากกว่า ชุดหนึ่งเรียกว่า data อีกชุดเรียกว่า rsrc และบนดิสก์ทั้งคู่ก็เป็นเพียง byte stream
      แต่โดยปกติ resource fork จะเก็บโครงสร้างของชิ้นข้อมูลขนาดเล็กที่ทำดัชนีด้วย type code 4 ไบต์ และ ID จำนวนเต็ม 2 ไบต์
      แอปพลิเคชัน Mac บน 68K ใส่แทบทุกอย่างไว้ใน resource fork ไม่ว่าจะเป็นโค้ด เมนู กล่องโต้ตอบ รูปภาพ ไอคอน สตริง ฯลฯ และถ้าคัดลอกแอป Mac รุ่นเก่าไปยัง PC หรือ Unix โดยไม่แปลงไฟล์ ก็จะดูเหมือนไฟล์ว่าง
      ดังนั้นหากจะส่งแอป Mac ผ่านเครือข่าย ก็ต้องเข้ารหัสให้เป็นสตรีมเดียว และในยุคแรกใช้ BinHex .hqx หรือ MacBinary .bin ต่อมาจึงใช้ไฟล์เก็บถาวร Stuffit .sit
      เหตุผลที่โครงสร้างแบบนี้ไม่เข้ากับ inode คือมันแทบจะเหมือนการพยายามยัดไฟล์ทั้งไฟล์เข้าไปทั้งก้อน แม้โครงสร้าง resource fork เองจะมีข้อจำกัด 16MB แต่ถ้าถือว่าเป็น data stream แยกต่างหาก ก็ทำให้ใหญ่ได้ตามต้องการ
    • เท่าที่จำได้ resource fork มีสิ่งที่สมัยก่อนแก้ไขด้วย ResEdit อยู่ในนั้น เช่น ไอคอน, GUI resources ต่าง ๆ รวมถึงข้อความและแอสเซตสำหรับการแปลก็ได้
      เช่น ปลั๊กอิน Escape Velocity ใช้ resource type แบบกำหนดเอง และแก้ไขได้ง่ายด้วยปลั๊กอิน ResEdit
    • ใน NTFS ก็มี Alternate Data Streams เช่นกัน แต่คิดว่าแทบไม่มีใครใช้
      https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(AD...
    • เมทาดาทาของแอปพลิเคชัน เช่น รูปแบบไฟล์ที่แอปเปิดได้ หรือเมื่อ creator code ตรงกับแอปพลิเคชันแล้วควรใช้ไอคอนใด จะถูกเก็บไว้ใน resource fork ของแอปพลิเคชันนั้น แต่เมทาดาทาของไฟล์ไม่ได้เก็บไว้ใน resource fork
      file type, creator code, บิต locked, invisible, bozo ฯลฯ ถูกเก็บไว้ในระบบไฟล์เสมอ
      ตัวอย่างเช่น ดูคำอธิบายรูปแบบดิสก์ MFS ได้ที่: https://wiki.osdev.org/MFS#File_Directory_Blocks
    • การทำ dual-format CD/DVD เพราะข้อมูลแบบ forked นั้นค่อนข้างน่าสนใจ ตอนแรกเป็นเหมือนทริกอย่างหนึ่ง แต่ภายหลังซอฟต์แวร์เขียนแผ่นบน Mac ก็จัดการให้ได้ง่าย ๆ
      การทำ DVD สำหรับบูต Mac ก็ไม่ใช่เรื่องง่ายเหมือนกัน

  • จำได้ว่าสมัยก่อนเคยมีวิธีปิดการสร้าง .DS_Store แต่ Apple เอาออกไป และไม่เข้าใจเลยว่าทำไมถึงเปลี่ยนแบบนั้น
    สุดท้ายถึงขั้นเขียนโปรแกรมเองเพื่อเฝ้าดูทั้งระบบไฟล์ แล้วลบ .DS_Store ทันทีที่มันถูกสร้างขึ้น
    [0] https://github.com/slmjkdbtl/dskill

    • ปิดได้บน network volume
      defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
      https://support.apple.com/en-us/102064
      จำไม่ได้ว่าเคยมีวิธีปิดบน local volume หรือไม่
    • Apple ทำให้เละเทะจริง ๆ ตั้งแต่เริ่มสร้างไฟล์ที่ขึ้นต้นด้วย . ไว้ที่รากของระบบไฟล์
      หลังจาก .DS_Store ได้รับอนุญาตแล้ว ดูเหมือนวิศวกรคนอื่น ๆ ก็อนุมัติสิ่งอย่าง .fseventsd, .Spotlight-V100 ได้ง่าย ๆ เช่นกัน
      ไม่รู้เห็นระบบไฟล์ที่ “ปนเปื้อน” เพราะไฟล์พวกนี้มาแล้วกี่ครั้ง ส่วนใหญ่เป็น SD card หรือ USB flash drive แต่บางครั้งก็มีกรณีที่แย่กว่านั้นมาก
      ปกติในสถานการณ์แบบนี้จะรัน rm -rf .DS_Store .Trashes ._.Trashes .fseventsd .Spotlight-V100 แล้วรีบ eject ไดรฟ์ก่อนที่จะมีอะไรถูกเขียนเพิ่ม
      โดยเฉพาะเวลาต้องคัดลอกข้อมูลจากดิสก์ที่สภาพกำลังแย่ลง สิ่งที่ไม่อยากให้เกิดที่สุดคือการเริ่มทำดัชนีทั้งดิสก์และเขียนลงดิสก์
      พูดจริง ๆ เรื่องแบบนี้ควรมี ตัวเลือกในการตั้งค่า
    • find / -name ".DS_Store" -exec rm {} \; 2>/dev/null
      เอาอันนี้ใส่สคริปต์แล้วเพิ่มลงใน crontab ก็ได้

  • .DS_Store ดูเหมือนเป็นการออกแบบที่โชคร้ายจริง ๆ แม้จะมีจุดประสงค์และมีวิธีเลี่ยงหลายอย่าง แต่ในทางปฏิบัติมันกลายเป็นสิ่งที่แพร่ ไฟล์ขยะ ให้กับ 99% ของคนที่เจอ
    ในแง่ของการเก็บงานด้านประสบการณ์ผู้ใช้แล้ว นี่ดูไม่ค่อยเป็น Apple เท่าไร
    ผมโตมากับการใช้ System 7.5, OS X และ Windows ควบคู่กัน และ Mac เคยเป็นฝั่งที่ไม่บังคับให้ผู้ใช้ต้องเห็นรายละเอียดการทำงานภายใน เช่น ไฟล์ที่ไม่จำเป็น รูปแบบไฟล์ หรือ “คอมพิวเตอร์ทำงานข้างในอย่างไร”
    ดังนั้นการที่ไฟล์นี้โผล่ขึ้นมาตามที่ต่าง ๆ จึงรู้สึกแปลกมาก เพราะไม่ตรงกับ mental model ที่ผมมีต่อ Mac เลย

    • คนที่อยู่แต่ในระบบนิเวศของ Apple จะไม่มีวันเห็นไฟล์ .DS_Store เลย เว้นแต่จะใช้เทอร์มินัล
      ตอนนี้ Finder ไม่แสดงไฟล์เหล่านี้แล้ว แม้จะเปิดการแสดงไฟล์ซ่อนก็ตาม
      แต่ตอนแชร์ไฟล์จาก Mac ให้ผู้ใช้ Windows มันดูรกตาจริง ๆ และผมคิดว่าอาจสร้างความประทับใจแรกที่ไม่ดีให้คนที่กำลังคิดจะย้ายมาใช้ Mac ได้
    • คุณภาพการเก็บงาน ของ Apple มักอยู่ใกล้ผิวหน้ามากกว่าภายในเสมอ

  • ไม่เข้าใจว่าทำไมมันต้องอยู่ในโฟลเดอร์เดียวกันด้วย ระบบปฏิบัติการจะมี ฐานข้อมูลเล็ก ๆ ของตัวเองไว้ที่ไหนสักแห่ง แล้วอ้างอิงแต่ละ path ไม่ได้หรือ?

    • เจตนาคือให้ metadata อย่าง label ของไฟล์ย้ายตามไปด้วย ไม่ว่าจะใช้ไดรฟ์เครือข่ายจากอุปกรณ์ไหนก็ตาม
    • การวางไว้ในโฟลเดอร์ยังมีข้อดีคือเมื่อโฟลเดอร์ถูกลบ มันก็จะถูกลบไปด้วยโดยธรรมชาติ

  • เห็นด้วยกับคำพูดที่ว่า “ควรถูกสร้างก็ต่อเมื่อผู้ใช้ปรับการตั้งค่าการแสดงผลจริง ๆ หรือกำหนดตำแหน่งไอคอนในโฟลเดอร์ด้วยตนเองเท่านั้น” แต่ในความเป็นจริง แค่เข้าไปดูโฟลเดอร์ก็แทบรับประกันได้ว่าจะมี .DS_Store ถูกสร้างขึ้นมา
    นี่เป็นเรื่องที่ผมหงุดหงิดกับ Finder มากที่สุด
    การที่สามารถปรับแต่งหน้าตาและขนาดของหน้าต่างแต่ละโฟลเดอร์ได้หลากหลายแบบเหมือน Classic Mac OS Finder เป็นฟีเจอร์ที่ดีมากจริง ๆ
    แต่แค่ผ่านโฟลเดอร์เดียวกันนั้นด้วยหน้าต่างแบบ browser การปรับแต่งส่วนใหญ่ก็จะถูกเขียนทับด้วยการตั้งค่าหน้าต่าง browser แม้ไม่ได้เปลี่ยนอะไรเลย
    ถ้ามันพังง่ายขนาดนี้ ก็ไม่มีความหมายที่จะอนุญาตให้ปรับแต่งได้ยอดเยี่ยมขนาดนั้น
    ผมเปิดโฟลเดอร์ Applications ด้วยคีย์ลัด global แต่ต่อให้อยากตกแต่งหน้าต่างนั้นก็ไม่มีประโยชน์ ทุกครั้งที่กดคีย์ลัดก็ไม่รู้ว่าจะได้เห็นอะไร และมันถูกรีเซ็ตตลอด
    เหตุผลคือ Finder ไม่มีวิธีกำหนดโครงหน้าต่าง browser เริ่มต้น แต่กลับทิ้งการตั้งค่า browser ปัจจุบันไว้ในแต่ละโฟลเดอร์ที่เข้าไปเยือนแทน น่าหงุดหงิดจริง ๆ

    • ก่อน Darwin โฟลเดอร์ที่เปิดหนึ่งโฟลเดอร์สอดคล้องกับหน้าต่างหนึ่งหน้าต่าง และมีผู้ใช้เพียงคนเดียว วิธีนี้จึงเข้ากันได้ดี
      ผมชอบและคิดถึงมากที่หน้าต่างเดิมเด้งขึ้นมาด้านหน้าในสภาพเดียวกับที่ปล่อยไว้ครั้งล่าสุด
    • แม้จะไม่ใช่ global แต่ใน Finder สามารถเปิดโฟลเดอร์ Applications ด้วย cmd-shift-A และเปิดโฟลเดอร์ Utilities ด้วย cmd-shift-U ได้

  • ผมไม่ใช่ผู้ใช้ Mac เลยหงุดหงิดเสมอเวลาใน .tgz ที่ได้จากที่อย่าง GitHub มี .DS_Store อัดอยู่เต็มไปหมด
    macOS น่าจะใช้ GNU tar อยู่ แต่ค่อนข้างแปลกใจที่ไม่ได้แก้หรือกำหนดค่าให้ ignore .DS_Store เป็นค่าเริ่มต้น

    • แม้จะไม่ใช่ค่าเริ่มต้น แต่สามารถทำให้เป็นแบบนั้นได้
      ถ้า export COPYFILE_DISABLE=true แล้ว tar จะข้ามไฟล์ .DS_Store
    • ยูทิลิตี Unix ส่วนใหญ่ของ Mac ไม่ได้ถูก Apple ปรับแต่งเป็นพิเศษ แต่มาจาก FreeBSD แทบจะตรง ๆ

  • ควรค่าแก่การพูดถึงวิธีปิดการสร้างไฟล์ .DS_Store เป็นค่าเริ่มต้นเมื่อเรียกดู network volume ไม่อย่างนั้นแค่เดินดูด้วย Finder เวลาแก้ไขของไดเรกทอรีก็เปลี่ยนแล้ว ซึ่งแย่มากจริง ๆ
    https://old.reddit.com/r/MacOS/comments/lvju40/comment/gpc8i...

    • macOS สมัยนี้เรื่องมากขึ้น ผมดูใน Finder ว่ามี .DS_Store อยู่ใน network volume ไหม เหมือนจะไม่มี แต่พอไปดูในเทอร์มินัลกลับมีอยู่จริง
      ตอนนี้ไว้ใจฟีเจอร์แสดงไฟล์ซ่อนของ Finder ไม่ได้แล้ว เพราะแทนที่จะแสดงไฟล์ซ่อนทั้งหมด มันแสดงเฉพาะไฟล์ซ่อนที่ Finder ตัดสินว่าผู้ใช้ควรสนใจเท่านั้น
      network share ของผมเป็น Synology ในเครื่องเลยไม่ใช่ปัญหาใหญ่ แต่ในที่ทำงานไฟล์พวกนี้ทำให้สถานการณ์ค่อนข้างรกเละเทะ
    • ส่วนตัวผมให้ผู้ใช้ Mac ตั้งค่านี้ก่อนจะได้รับสิทธิ์เขียนลง network share ผมมองว่าเป็น มารยาทในการใช้ร่วมกัน ที่สมเหตุสมผล
    • ถ้าดูแล Samba อยู่ ก็สามารถตั้งค่า Samba ให้เพิกเฉยต่อคำขอสร้างไฟล์พวกนี้ไปเลยได้

  • ยังมีไฟล์จุดขีดล่าง (._) ด้วย มีวิธีปิดไม่ให้ไฟล์แบบนี้ถูกสร้างขึ้นบน network share ไหม?
    [0] https://superuser.com/questions/212896/is-there-any-way-to-p...

  • โชคดีที่ถ้าใช้ตัวจัดการไฟล์ Dired ของ Emacs ก็สามารถทำเป็นมองไม่เห็นไฟล์เล็ก ๆ น่ารำคาญพวกนี้ รวมถึงไฟล์ที่การรัน LaTeX สร้างขึ้นมาได้ง่าย ๆ
    (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\\)$")