ทำไม '.' ลิงค์ยากใน Unix?

ฉันเห็นคำอธิบายมากมายว่าเหตุใดลิงก์จึงนับเป็นไดเรกทอรีว่างในระบบปฏิบัติการ Unix ที่ใช้เป็น 2 แทนที่จะเป็น 1 พวกเขาทั้งหมดบอกว่าเป็นเพราะ '' ' ไดเรกทอรีซึ่งทุกไดเรกทอรีมีตัวชี้กลับไปเอง ฉันเข้าใจว่าทำไมการมีแนวคิด '.' มีประโยชน์สำหรับการระบุพา ธ ที่เกี่ยวข้อง แต่สิ่งที่ได้รับจากการใช้มันในระดับระบบไฟล์? ทำไมไม่เพียงแค่มีเชลล์หรือการเรียกระบบที่ใช้พา ธ รู้วิธีตีความมัน

นั่นคือ '.. ' เป็นลิงก์จริงทำให้ฉันมีเหตุผลมากกว่านี้ - ระบบไฟล์จำเป็นต้องเก็บตัวชี้กลับไปยังไดเรกทอรีหลักเพื่อนำทางไปยังมัน แต่ฉันไม่เห็นว่าทำไม '.' การมีลิงค์จริงเป็นสิ่งจำเป็น ดูเหมือนว่ามันจะนำไปสู่กรณีพิเศษที่น่าเกลียดในการนำไปใช้ - คุณคิดว่าคุณสามารถเพิ่มพื้นที่ว่างที่ใช้โดย inodes ที่มีลิงค์นับน้อยกว่า 1 แต่ถ้าเป็นไดเรกทอรีคุณจะต้องตรวจสอบหา ลิงค์นับน้อยกว่า 2 ทำไมต้องมีความไม่ลงรอยกัน?

คำถามที่น่าสนใจแน่นอน เมื่อเห็นแวบแรกฉันเห็นข้อดีดังต่อไปนี้:

ก่อนอื่นคุณต้องระบุว่าการตีความ " ." เป็นไดเรกทอรีปัจจุบันอาจทำได้โดยเชลล์หรือโดยการเรียกของระบบ แต่การมีจุดเข้าในไดเรกทอรีจริงเอาความจำเป็นและบังคับความมั่นคงในระดับที่ต่ำกว่านี้

แต่ฉันไม่คิดว่านี่เป็นแนวคิดพื้นฐานที่อยู่เบื้องหลังการตัดสินใจออกแบบนี้

เมื่อไฟล์ถูกสร้างหรือลบออกจากไดเรกทอรีการประทับเวลาการปรับเปลี่ยนไดเรกทอรีจะต้องได้รับการปรับปรุงเช่นกัน เวลาประทับนี้ถูกเก็บไว้ใน inode หมายเลขไอโหนดจะถูกเก็บไว้ในรายการไดเรกทอรีที่สอดคล้องกัน

หากรายการจุดไม่มีอยู่ที่รูทีนจะต้องค้นหาหมายเลข inode ที่รายการสำหรับไดเรกทอรีนี้ในไดเรกทอรีหลักซึ่งจะทำให้การค้นหาไดเรกทอรีอีกครั้ง

แต่โชคดีที่มีรายการจุดในไดเรกทอรีปัจจุบัน รูทีนที่เพิ่มหรือลบไฟล์ในไดเรกทอรีปัจจุบันเพียงแค่ต้องย้อนกลับไปที่รายการแรก (โดยที่จุดรายการมักจะอยู่) และทันทีพบหมายเลข inode สำหรับไดเรกทอรีปัจจุบัน

มีสิ่งที่สามที่ดีเกี่ยวกับรายการจุด:

เมื่อfsckตรวจสอบระบบไฟล์ที่เน่าเสียและต้องจัดการกับบล็อกที่ไม่ได้เชื่อมต่อที่ไม่ได้อยู่ในรายชื่อฟรีมันง่ายสำหรับตรวจสอบว่าบล็อกข้อมูล (เมื่อตีความว่าเป็นรายการไดเรกทอรี) มีรายการจุดที่ชี้ไปที่ไอโหนด ซึ่งจะชี้กลับไปยังบล็อกข้อมูลนี้ ถ้าเป็นเช่นนั้นบล็อกข้อมูลนี้อาจถูกพิจารณาว่าเป็นไดเรกทอรีที่หายไปซึ่งจะต้องทำการเชื่อมต่อใหม่

(อืม: ตอนนี้เป็นมหากาพย์ ... )

การออกแบบไดเรคทอรี่บนระบบไฟล์ยูนิกซ์ (ซึ่งปกติแล้วมักจะมีแต่ไม่จำเป็นต้องติดกับระบบปฏิบัติการยูนิกซ์) แสดงถึงการเข้าใจที่ยอดเยี่ยมซึ่งจริงๆแล้วเป็นการลดจำนวนกรณีพิเศษที่จำเป็น

'ไดเรกทอรี' เป็นเพียงไฟล์ในระบบไฟล์ เนื้อหาจริงทั้งหมดของไฟล์ในระบบไฟล์นั้นอยู่ในinodes (จากคำถามของคุณฉันจะเห็นว่าคุณได้ตระหนักถึงบางสิ่งนี้แล้ว) ไม่มีโครงสร้างใด ๆ ของ inodes บนดิสก์พวกมันเป็นเพียงกลุ่มก้อนใหญ่จำนวนหนึ่งไบต์แพร่กระจายอย่างเนยถั่วลิสงบนดิสก์ สิ่งนี้ไม่มีประโยชน์และแน่นอนว่าเป็นสิ่งที่น่ารังเกียจสำหรับทุกคนที่มีความเป็นระเบียบเรียบร้อย

เพียง inode พิเศษเป็นจำนวน inode 2 (ไม่ 0 หรือ 1 สำหรับเหตุผลของประเพณี); inode 2 เป็นไฟล์ไดเรกทอรีที่: ไดเรกทอรีราก เมื่อระบบทำการเมานต์ระบบไฟล์มันจะ 'รู้' ว่ามันต้อง readdir inode 2 เพื่อเริ่มต้นตัวมันเอง

ไฟล์ไดเรกทอรีเป็นเพียงไฟล์ที่มีโครงสร้างภายในซึ่งมีวัตถุประสงค์เพื่อให้ผู้อ่าน opendir (3) และเพื่อนอ่าน คุณสามารถดูโครงสร้างภายในของเอกสารใน dir (5) (ขึ้นอยู่กับระบบปฏิบัติการของคุณ); ถ้าคุณดูนั้นคุณจะเห็นว่ารายการไฟล์ไดเรกทอรีไม่มีข้อมูลเกี่ยวกับไฟล์ - เกือบทั้งหมดอยู่ในไฟล์ inode หนึ่งในสองสามสิ่งที่พิเศษเกี่ยวกับไฟล์นี้คือฟังก์ชั่นเปิด (2) จะได้รับข้อผิดพลาดหากคุณพยายามเปิดไฟล์ไดเรกทอรีด้วยโหมดที่อนุญาตให้เขียนได้ คำสั่งอื่น ๆ (เพื่อเลือกเพียงตัวอย่างเดียวhexdump) จะปฏิเสธที่จะดำเนินการตามปกติกับไฟล์ไดเรกทอรีเพียงเพราะนั่นอาจไม่ใช่สิ่งที่คุณต้องการ (แต่เป็นกรณีพิเศษของพวกเขาไม่ใช่ระบบไฟล์)

การเชื่อมโยงอย่างหนักเป็นอะไรมากหรือน้อยกว่ารายการในแผนที่ไฟล์ไดเรกทอรีของ คุณสามารถมีสอง (หรือมากกว่า) รายการในแผนที่ซึ่งแผนที่ทั้งสองไปยังหมายเลข inode เดียวกัน: ดังนั้น inode นั้นจึงมีฮาร์ดลิงก์สอง (หรือมากกว่า) นอกจากนี้ยังอธิบายว่าทำไมไฟล์ทุกไฟล์มีฮาร์ดลิงก์อย่างน้อยหนึ่งไฟล์ inode มีจำนวนการอ้างอิงซึ่งบันทึกจำนวนครั้งที่ inode ถูกกล่าวถึงในไฟล์ไดเร็กทอรีที่ใดที่หนึ่งในระบบไฟล์ (นี่คือหมายเลขที่คุณเห็นเมื่อคุณทำls -l)

ตกลง: เรามาถึงจุดนี้แล้ว

ไฟล์ไดเรกทอรีคือแผนที่ของสตริง ('ชื่อไฟล์') กับตัวเลข (หมายเลข inode) หมายเลข inode เหล่านั้นเป็นตัวเลขของ inodes ของไฟล์ซึ่งอยู่ในไดเรคทอรีนั้น ไฟล์ที่อยู่ใน 'ไดเรกทอรี' นั้นอาจรวมถึงไฟล์ไดเรกทอรีอื่น ๆ ดังนั้นหมายเลข inode ของพวกเขาจะอยู่ในรายชื่อในไดเรกทอรี ดังนั้นหากคุณมีไฟล์ไฟล์/tmp/foo/barไดเรกทอรีจะfooมีรายการสำหรับbarการจับคู่สตริงนั้นกับ inode สำหรับไฟล์นั้น นอกจากนี้ยังมีรายการในแฟ้มไดเรกทอรี/tmpสำหรับแฟ้มไดเรกทอรีfooซึ่งเป็น 'ใน' /tmpไดเรกทอรี

เมื่อคุณสร้างไดเรกทอรีด้วย mkdir (2) ฟังก์ชันนั้น

1. สร้างไฟล์ไดเรกทอรี (ที่มีหมายเลข inode บางส่วน) ด้วยโครงสร้างภายในที่ถูกต้อง
2. เพิ่มรายการไปยังไดเรกทอรีหลัก, การแมปชื่อไดเรกทอรีใหม่ไปยัง inode ใหม่นี้ (ที่บัญชีสำหรับหนึ่งในลิงค์)
3. เพิ่มรายการในไดเรกทอรีใหม่โดยจับคู่สตริง '.' เป็น inode เดียวกัน (บัญชีนี้มีลิงก์อื่น) และ
4. เพิ่มรายการอื่นไปยังไดเรกทอรีใหม่จับคู่สตริง '.. ' ไปยัง inode ของไฟล์ไดเรกทอรีที่แก้ไขในขั้นตอนที่ (2) (บัญชีนี้มีลิงก์จำนวนมากที่คุณเห็นในไฟล์ไดเรกทอรีซึ่งมีไดเรกทอรีย่อย )

ผลลัพธ์ที่ได้คือ (เกือบ) เฉพาะกรณีพิเศษคือ:

• ฟังก์ชั่นเปิด (2) พยายามที่จะทำให้ตัวเองยิงยากขึ้นโดยการป้องกันไม่ให้คุณเปิดไฟล์ไดเรกทอรีสำหรับการเขียน
• ฟังก์ชั่น mkdir (2) ทำสิ่งที่ดีและง่ายโดยเพิ่มรายการพิเศษสองรายการ ('.' และ '.. ') ไปยังไฟล์ไดเรกทอรีใหม่เพื่อให้สะดวกในการเคลื่อนย้ายระบบไฟล์ ฉันสงสัยว่าระบบไฟล์จะทำงานได้อย่างสมบูรณ์แบบหากไม่มี '.' และ '.. ' แต่จะเป็นความเจ็บปวดที่จะใช้
• ไฟล์ไดเรกทอรีเป็นหนึ่งในไม่กี่ประเภทของไฟล์ที่ถูกตั้งค่าสถานะเป็น 'พิเศษ' - นี่คือสิ่งที่บอกสิ่งต่างๆเช่น open (2) ให้ทำงานแตกต่างกันเล็กน้อย ดูst_modeใน stat (2)

(คัดลอกมาจากคำถามดั้งเดิมของ stackoverflow 2011-10-20)