เหตุใดฮาร์ดลิงก์ไปยังไดเรกทอรีที่ไม่ได้รับอนุญาตใน UNIX / Linux

130

ฉันอ่านในตำราเรียนที่ Unix / Linux ไม่อนุญาตการเชื่อมโยงอย่างหนักไปยังไดเรกทอรี แต่อนุญาตการเชื่อมโยงที่อ่อนนุ่ม เป็นเพราะเมื่อเรามีรอบและถ้าเราสร้างฮาร์ดลิงก์และหลังจากเวลาที่เราลบไฟล์ต้นฉบับมันจะชี้ไปที่ค่าขยะบางอย่าง?

หากวัฏจักรคือเหตุผลเดียวที่อยู่เบื้องหลังไม่อนุญาตให้มีการเชื่อมโยงอย่างหนักแล้วทำไมลิงก์แบบนุ่มไปยังไดเรกทอรีที่ได้รับอนุญาต?

— user3539
แหล่งที่มา

2

ควร..ชี้ไปที่ใด โดยเฉพาะอย่างยิ่งหลังจากลบฮาร์ดไดรฟ์ไปยังไดเรกทอรีนี้ในไดเรกทอรีชี้ไปที่..? มันต้องชี้ไปที่ไหนสักแห่ง

— Thorbjørn Ravn Andersen

2

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

— คู่ปรับ Shot

ฉันชอบคำอธิบายนี้ รัดกุมและง่ายต่อการอ่านและ / หรือหาง

— เทรเวอร์บอยด์สมิ ธ

143

นี่เป็นเพียงความคิดที่ไม่ดีเนื่องจากไม่มีวิธีที่จะบอกความแตกต่างระหว่างฮาร์ดลิงก์และชื่อเดิม

การอนุญาตให้ฮาร์ดลิงก์ไปยังไดเรกทอรีต่างๆอาจทำลายโครงสร้างกราฟ acyclic โดยตรงของระบบไฟล์ซึ่งอาจสร้างไดเรกทอรีลูปและไดเรกทอรีย่อยไดเรกทอรีที่ห้อยอยู่ซึ่งจะทำให้fsckเกิดข้อผิดพลาดและข้อผิดพลาดอื่น ๆ

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

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

ฮาร์ดลิงก์เป็นเพียงรายการไดเรกทอรีพิเศษที่ชี้ไปที่ไอโหนดนั้น เมื่อคุณls -lจำนวนหลังการอนุญาตคือการนับลิงค์ที่มีชื่อ ไฟล์ปกติส่วนใหญ่จะมีลิงค์เดียว การสร้างฮาร์ดลิงก์ใหม่ไปยังไฟล์จะทำให้ชื่อไฟล์ทั้งสองชี้ไปที่ไอโหนดเดียวกัน บันทึก:

% ls -l test
ls: test: No such file or directory
% touch test
% ls -l test
-rw-r--r--  1 danny  staff  0 Oct 13 17:58 test
% ln test test2
% ls -l test*
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
% touch test3
% ls -l test*
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
-rw-r--r--  1 danny  staff  0 Oct 13 17:59 test3
            ^
            ^ this is the link count

ตอนนี้คุณสามารถเห็นได้อย่างชัดเจนว่าไม่มีสิ่งใดเป็นฮาร์ดลิงก์ ฮาร์ดลิงก์เหมือนกับชื่อปกติ ในตัวอย่างด้านบนtestหรือtest2ไฟล์ต้นฉบับใดและไฟล์ใดที่เป็นฮาร์ดลิงก์ ในตอนท้ายคุณจะไม่สามารถบอกได้อย่างแท้จริง (แม้กระทั่งในการประทับเวลา) เพราะทั้งสองชื่อชี้ไปที่เนื้อหาเดียวกัน inode เดียวกัน:

% ls -li test*  
14445750 -rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
14445750 -rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
14445892 -rw-r--r--  1 danny  staff  0 Oct 13 17:59 test3

การ-iตั้งค่าสถานะเพื่อlsแสดงหมายเลขไอโหนดในตอนต้นของบรรทัด สังเกตวิธีtestและtest2มีหมายเลขไอโหนดเดียวกัน แต่test3มีหมายเลขไอโหนดอื่น

ทีนี้ถ้าคุณได้รับอนุญาตให้ทำสิ่งนี้กับไดเร็กตอรี่สองไดเร็กตอรี่ที่ต่างกันในจุดต่าง ๆ ในระบบไฟล์อาจชี้ไปที่สิ่งเดียวกัน. ในความเป็นจริง subdir สามารถชี้กลับไปที่ปู่ย่าตายายของมันสร้างวง

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

Symlinks เป็นสัตว์ร้ายที่แตกต่างกันโดยสิ้นเชิงซึ่งเป็น "ไฟล์" ชนิดพิเศษที่ API ระบบไฟล์ไฟล์จำนวนมากมักจะติดตามโดยอัตโนมัติ หมายเหตุ symlink สามารถชี้ไปยังปลายทางที่ไม่มีอยู่ได้เนื่องจากจะชี้ไปที่ชื่อและไม่เชื่อมต่อโดยตรงกับ inode แนวคิดดังกล่าวไม่สมเหตุสมผลกับฮาร์ดลิงก์เนื่องจากการมีอยู่ของ "ฮาร์ดลิงก์" หมายถึงไฟล์ที่มีอยู่

เหตุใดจึงสามารถduจัดการกับ symlink ได้อย่างง่ายดายและไม่เชื่อมโยงที่ยาก เราสามารถเห็นได้ว่าการเชื่อมโยงฮาร์ดนั้นแยกไม่ออกจากรายการไดเรกทอรีปกติ อย่างไรก็ตาม Symlinks มีความพิเศษตรวจจับได้และข้ามได้! duสังเกตว่า symlink นั้นเป็น symlink และข้ามมันไปจนหมด!

% ls -l 
total 4
drwxr-xr-x  3 danny  staff  102 Oct 13 18:14 test1/
lrwxr-xr-x  1 danny  staff    5 Oct 13 18:13 test2@ -> test1
% du -ah
242M    ./test1/bigfile
242M    ./test1
4.0K    ./test2
242M    .

— Danny Dulai
แหล่งที่มา

7

Allowing hard links to directories would break the directed acyclic graph structure of the filesystem. คุณช่วยอธิบายเพิ่มเติมเกี่ยวกับปัญหารอบการใช้ฮาร์ดลิงก์ได้ไหม? ทำไมมันถึงตกลงกับ symlinks

— user3539

33

ดูเหมือนว่าพวกเขาจะได้รับอนุญาตให้ใช้งานบน Mac โดยเพิ่มการตรวจจับรอบในการเชื่อมโยงของระบบ () และปฏิเสธที่จะอนุญาตให้คุณสร้างไดเรกทอรีฮาร์ดลิงก์ถ้ามันจะสร้างรอบ ดูเหมือนจะเป็นทางออกที่สมเหตุสมผล

— psusi

10

@psusi mkdir -pa / b; nocheckln ca; mv ca / b; - nocheckln มี ln เชิงทฤษฎีที่ไม่ตรวจสอบ args ของไดเรกทอรีและเพิ่งผ่านไปยังลิงก์และเนื่องจากไม่มีการวนรอบเราจึงเก่งในการสร้าง 'c' จากนั้นเราย้าย 'c' ไปเป็น 'a / b' และวัฏจักรถูกสร้างขึ้นจาก a / b / c -> a / - การตรวจสอบในลิงก์ () ไม่ดีพอ

— Danny Dulai

3

รอบไม่ดีมาก Windows มีปัญหากับ "junctions" ซึ่งเป็นไดเรกทอรีการเชื่อมโยงอย่างหนัก หากคุณใช้สิทธิ์โดยไม่ได้ตั้งใจกับโปรไฟล์ทั้งหมดของคุณมันจะเปิดเผยชุดของทางแยกที่สร้างวงรอบไม่สิ้นสุด การเรียกซ้ำผ่านไดเรกทอรีจะเรียกใช้ซ้ำจนกระทั่งข้อจำกัดความยาวพา ธ หยุดลง

— doug65536

4

@ WhiteWinterWolf ตามลิงก์นี้พวกเขาได้เพิ่มการสนับสนุนเป็นพิเศษสำหรับไทม์แมชชีน แต่อนุญาตให้รูททำได้เท่านั้น: superuser.com/questions/360926/ …

— psusi

14

..ด้วยข้อยกเว้นของจุดเชื่อมต่อไดเรกทอรีแต่ละคนมีหนึ่งเดียวผู้ปกครอง:

วิธีหนึ่งในการทำpwdคือตรวจสอบอุปกรณ์: inode สำหรับ '.' และ '.. ' หากเหมือนกันคุณจะมาถึงรูทของระบบไฟล์ มิฉะนั้นค้นหาชื่อของไดเรกทอรีปัจจุบันในพาเรนต์กดที่บนสแต็กและเริ่มเปรียบเทียบ '../' ด้วย '../ .. ' จากนั้น '../../' ด้วย '../../ .. ' เป็นต้นเมื่อคุณกดรูตแล้วให้เริ่มต้น popping และพิมพ์ชื่อจากสแต็ก อัลกอริทึมนี้อาศัยข้อเท็จจริงที่ว่าแต่ละไดเรกทอรีมีเพียงหนึ่งเดียวเท่านั้น

หากอนุญาตให้เชื่อมโยงไปยังไดเรกทอรีอย่างหนักหนึ่งในผู้ปกครองหลายคนควร..ชี้ไปที่ใด นั่นคือเหตุผลหนึ่งที่น่าสนใจว่าทำไมไม่อนุญาตให้มีการลิงก์ไปยังไดเรกทอรี

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

— Joe Inwap
แหล่งที่มา

3

ไม่แน่ใจเกี่ยวกับสิ่งนี้ หากเราคิดว่า..เป็นเสมือน hardlink ของผู้ปกครองไม่มีเหตุผลทางเทคนิคที่เป้าหมายของลิงก์นั้นสามารถมีลิงค์อื่น ๆ ได้ pwdจะต้องใช้อัลกอริทึมที่แตกต่างเพื่อแก้ไขเส้นทาง

— Benubird

13

คุณสามารถใช้การเชื่อมต่อเชื่อมโยงเพื่อจำลองไดเรกทอรีเชื่อมโยงที่ยาก

sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory
sudo umount /else/dummy_but_existing_directory

— zainengineer
แหล่งที่มา

7

ฉันต้องการเพิ่มคะแนนเพิ่มเติมอีกเล็กน้อยเกี่ยวกับคำถามนี้ ลิงค์ยากสำหรับไดเรกทอรีได้รับอนุญาตใน linux แต่ในทางที่ จำกัด

วิธีหนึ่งที่เราสามารถทดสอบได้คือเมื่อเราแสดงรายการเนื้อหาของไดเรกทอรีที่เราพบสองไดเรกทอรีพิเศษ "." และ ".. " อย่างที่เรารู้ "." ชี้ไปที่ไดเรกทอรีเดียวกันและ ".. " ชี้ไปที่ไดเรกทอรีหลัก

ดังนั้นให้สร้างแผนผังไดเรกทอรีที่ "a" เป็นไดเรกทอรีหลักที่มีไดเรกทอรี "b" เป็นลูกของมัน

 a
 `-- b

จดบันทึก inode ของไดเรกทอรี "a" และเมื่อเราทำls -laจากไดเรกทอรี "a" เราจะเห็นได้ว่า " ไดเรกทอรียังชี้ไปที่ไอโหนดเดียวกัน

797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 a

และที่นี่เราจะพบว่าไดเรกทอรี "a" มีสามฮาร์ดลิงก์ นี่เป็นเพราะ inode 797358 มีสามฮาร์ดลิงก์ในชื่อ "." ภายในไดเรกทอรี "a" และชื่อเป็น ".. " ภายในไดเรกทอรี "b" และอีกหนึ่งชื่อ "a" itslef

$ ls -ali a/
797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 .

$ ls -ali a/b/
797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 ..

ดังนั้นที่นี่เราสามารถเข้าใจได้ว่ามีลิงก์ไปยังไดเรกทอรีสำหรับเชื่อมต่อกับไดเรกทอรีหลักและไดเรกทอรีย่อยเท่านั้น ดังนั้นไดเรกทอรีที่ไม่มีลูกจะมี 2 ฮาร์ดลิงก์เท่านั้นดังนั้นไดเรกทอรี "b" จะมีสองฮาร์ดลิงก์เท่านั้น

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

เนื่องจากระบบไฟล์ถูกจัดเป็น tree และ tree ไม่สามารถมีการอ้างอิงแบบวนซ้ำได้จึงควรหลีกเลี่ยง

— Kannan Mohan
แหล่งที่มา

1

ตัวอย่างที่ดี มันเคลียร์ข้อสงสัยของฉัน ดังนั้นกรณีเหล่านี้ได้รับการจัดการในวิธีพิเศษเพื่อหลีกเลี่ยงการวนซ้ำไม่สิ้นสุด ขวา?

— G Gill

1

เนื่องจากเรามีวิธี จำกัด การอนุญาตให้ลิงก์ฮาร์ดไดรฟ์สำหรับไดเรกทอรีเช่น ".. " และ "." เราจะไม่สามารถเข้าถึงห่วงอนันต์และดังนั้นเราจะไม่จำเป็นต้องใช้วิธีการใด ๆ เป็นพิเศษเพื่อหลีกเลี่ยงผู้ที่พวกเขาจะไม่เกิดขึ้น :)

— คานโมฮัน

5

ไม่มีเหตุผลใด ๆ ต่อไปนี้ในการยกเลิกการเชื่อมโยงไปยังไดเรกทอรี แต่ละปัญหาค่อนข้างง่ายในการแก้:

รอบในโครงสร้างต้นไม้ทำให้เกิดการเคลื่อนที่ที่ยาก
ผู้ปกครองหลายคนซึ่งเป็น "ของจริง" คนใด
การรวบรวมขยะของระบบไฟล์

เหตุผลที่แท้จริง (ตามนัยโดย @ Thorbjørn Ravn Andersen) มาเมื่อคุณลบไดเรกทอรีที่มีพ่อแม่หลายคนจากไดเรกทอรีที่ชี้ไปตาม..:

สิ่งที่ควร..ชี้ไปที่?

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

ไม่ว่าจะด้วยวิธีใดก็ตามนี่จะเป็นค่าใช้จ่ายด้านประสิทธิภาพและความซับซ้อนเป็นพิเศษสำหรับข้อมูลเมตาของระบบไฟล์และ / หรือรหัสดังนั้นผู้ออกแบบจึงตัดสินใจที่จะไม่อนุญาต

— Lqueryvg
แหล่งที่มา

3

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

— jathd

2

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

— Lqueryvg

1

Sym ลิงก์ไปยัง dirs "ละเมิดซีแมนทิกส์และพฤติกรรมที่ตัดสิน" แต่พวกเขาก็ยังได้รับอนุญาต คำสั่งบางคำสั่งจำเป็นต้องมีตัวเลือกเพื่อควบคุมว่ามีการติดตามลิงก์ sym หรือไม่ (เช่น -L in find และ cp) เมื่อโปรแกรมดังต่อไปนี้ '.. ' มีความสับสนมากขึ้นดังนั้นความแตกต่างในเอาต์พุตจาก pwd และ / bin / pwd หลังจากผ่านลิงค์ sym ไม่มี "คำตอบ Unix"; เพียงแค่ออกแบบการตัดสินใจ อันนี้หมุนรอบสิ่งที่กลายเป็น ".. " ตามที่ฉันระบุไว้ในคำตอบของฉัน น่าเสียดายที่ '.. ' ไม่ได้กล่าวถึงแม้ในคำตอบที่คนอื่นโหวตให้อย่างเหนียมอาย

— Lqueryvg

BTW ฉันไม่ได้บอกว่าฉันชอบลิงค์ยากไปยัง dirs ไม่ใช่เลย. ฉันไม่ต้องการให้งานประจำวันของฉันหนักกว่านี้อีกแล้ว

— Lqueryvg

มันไม่ใช่สิ่งที่ POSIX พูด แต่ IMO '..' ควรจะมีไม่เคยมีแนวคิดระบบแฟ้มมติค่อนข้าง syntactically บนเส้นทางเพื่อที่ว่ามักจะหมายถึงa/.. .นี่คือการทำงานของ URL btw มันเป็นเบราว์เซอร์ที่แก้ปัญหา '.. ' ก่อนที่จะถึงเซิร์ฟเวอร์ และมันใช้งานได้ดี

— ybungalobill

3

การสร้างฮาร์ดลิงก์ในไดเรกทอรีจะไม่สามารถย้อนกลับได้ สมมติว่าเรามี:

/dir1
├──this.txt
├──directory
│  └──subfiles
└──etc

ฉัน hardlink /dir2มัน

ดังนั้น/dir2ตอนนี้ยังมีไฟล์และไดเรกทอรีทั้งหมดเหล่านี้

ถ้าฉันเปลี่ยนใจ ฉันทำไม่ได้rmdir /dir2(เพราะไม่ว่างเปล่า)

และถ้าฉันลบซ้ำแล้วซ้ำอีก/dir2มันจะถูกลบออก/dir1ด้วย

IMHO เป็นเหตุผลเพียงพอที่จะหลีกเลี่ยงปัญหานี้ได้!

แก้ไข:

ความคิดเห็นแนะนำให้ลบไดเรกทอรีโดยทำrmมัน แต่rmในไดเรกทอรีที่ไม่ว่างเปล่าล้มเหลวและพฤติกรรมนี้ต้องยังคงอยู่ไม่ว่าไดเรกทอรีนั้นจะมีการเชื่อมโยงอย่างหนักหรือไม่ก็ตาม ดังนั้นคุณไม่สามารถrmยกเลิกการเชื่อมโยงได้ มันจะต้องมีอาร์กิวเมนต์ใหม่rmเพียงเพื่อพูดว่า "ถ้า inode ไดเรกทอรีมีจำนวนอ้างอิง> 1 แล้วยกเลิกการเชื่อมโยงไดเรกทอรีเท่านั้น"

ซึ่งในทางกลับกันทำลายหลักการที่น่าประหลาดใจอย่างน้อยที่สุดนั่นก็หมายความว่าการลบฮาร์ดไดรฟ์ไดเรกทอรีที่ฉันเพิ่งสร้างนั้นไม่เหมือนกับการลบฮาร์ดไดรฟ์ไฟล์ปกติ ...

ฉันจะเรียบเรียงประโยคของฉันอีกครั้ง: หากไม่มีการพัฒนาเพิ่มเติมการสร้างฮาร์ดลิงก์จะไม่สามารถย้อนกลับได้ (เนื่องจากไม่มีคำสั่งปัจจุบันสามารถจัดการกับการลบโดยไม่เชื่อมโยงกับพฤติกรรมปัจจุบัน)

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

— Pierre-Olivier Vares
แหล่งที่มา

นั่นไม่ควรเป็นปัญหา ในกรณีของคุณเมื่อเราสร้างฮาร์ดลิงก์ไปยัง dir2 เราจะต้องทำการฮาร์ดลิงก์ไปยังเนื้อหาทั้งหมดใน dir1 และดังนั้นหากเราเปลี่ยนชื่อหรือลบ dir2 เพียงลิงค์พิเศษไปยัง inode จะถูกลบ และนั่นไม่ควรส่งผลกระทบต่อ dir1 และเนื้อหาเนื่องจากมีอย่างน้อยหนึ่งลิงก์ (dir1) ไปยัง inode

— Kannan Mohan

3

อาร์กิวเมนต์ของคุณไม่ถูกต้อง คุณเพียงแค่จะยกเลิกการเชื่อมโยงไม่ทำ rm -rf และหากจำนวนลิงก์ถึง 0 ระบบจะทราบได้ว่าสามารถลบเนื้อหาทั้งหมดได้เช่นกัน

— LtWorf

นั่นคือทั้งหมดที่rmอยู่ภายใต้ (ยกเลิกการเชื่อมโยง) โปรดดู: unix.stackexchange.com/questions/151951/…นี่ไม่ใช่ปัญหาจริงๆแล้วมันมีปัญหากับไฟล์ฮาร์ดลิงก์ การยกเลิกการเชื่อมโยงจะลบการอ้างอิงที่ระบุชื่อและลดจำนวนลิงก์ ความจริงที่ว่าrmdirจะไม่ลบไดเรกทอรีที่ไม่ว่างนั้นไม่เกี่ยวข้อง - มันจะไม่ทำdir1 เช่นนั้น ฮาร์ดลิงก์ไม่ใช่สำเนาของข้อมูล แต่เป็นไฟล์จริงเดียวกันดังนั้น "ลบ" ไฟล์ dir2 จะลบรายชื่อไดเรกทอรีสำหรับ dir1 คุณจะต้องยกเลิกการเชื่อมโยงเสมอ

— BryKKan

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

— Pierre-Olivier Vares

1

นี่เป็นคำอธิบายที่ดี เกี่ยวกับ "ผู้ปกครองหลายคนควร .. ชี้ไปที่" ทางออกหนึ่งอาจเป็นกระบวนการที่จะรักษาเส้นทาง wd แบบเต็มไม่ว่าจะเป็น inodes หรือเป็นสตริง inodes จะมีประสิทธิภาพมากกว่าเนื่องจากสามารถเปลี่ยนชื่อได้ อย่างน้อยในสมัยก่อนมี inode แบบ in-core สำหรับทุกไฟล์ที่เปิดที่เพิ่มขึ้นเมื่อใดก็ตามที่ไฟล์ถูกเปิดลดลงเมื่อปิด เมื่อมันมาถึงศูนย์มันและที่เก็บมันชี้ไปที่ว่าจะเป็นอิสระ เมื่อใครก็ตามที่ไม่ได้เปิดไฟล์อีกต่อไปมัน (การคัดลอกแบบ in-core) จะถูกยกเลิก สิ่งนี้จะรักษาพา ธ ให้ถูกต้องหากกระบวนการอื่นย้ายไดเรคทอรีไปยังไดเรกทอรีอื่นในขณะที่ไดเรกทอรีย่อยอยู่ในเส้นทางของกระบวนการอื่น คล้ายกับวิธีที่คุณสามารถลบไฟล์ที่เปิดอยู่ แต่มันจะถูกลบออกจากไดเรกทอรี

ไดเรกทอรีเชื่อมโยงยากที่เคยได้รับอนุญาตใน Bell Labs UNIX อย่างน้อย V6 และ V7 ไม่รู้เกี่ยวกับ Berkeley หรือใหม่กว่า ไม่จำเป็นต้องตั้งค่าสถานะ คุณทำลูปได้ไหม? ใช่อย่าทำอย่างนั้น มันชัดเจนมากว่าคุณกำลังทำอะไรถ้าคุณทำลูป Nether คุณควรฝึกปมผูกรอบคอของคุณในขณะที่คุณกำลังรอให้ถึงจุดที่จะกระโดดร่มออกจากเครื่องบินหากคุณมีปลายอีกด้านที่สะดวกแขวนจากตะขอบนหัวเป็นกลุ่ม

สิ่งที่ฉันหวังว่าจะทำในวันนี้คือการฮาร์ดลิงก์ lhome ไปที่บ้านเพื่อที่ฉันจะได้ / home / administ พร้อมใช้งานหรือไม่ / home ถูกปกคลุมด้วย automout ทั่วบ้าน automount ที่มี symlink ชื่อ administ to / lhome / บริหารธุรกิจ สิ่งนี้ทำให้ฉันมีบัญชีผู้ดูแลระบบที่ทำงานโดยไม่คำนึงถึงสถานะของระบบไฟล์หลักของฉัน นี่คือการทดลองสำหรับ linux แต่ฉันคิดว่าเรียนรู้ครั้งเดียวสำหรับ SunOS จาก UCB ที่ดำเนินการอัตโนมัติในระดับสตริง ASCII เป็นการยากที่จะเห็นว่าพวกเขาสามารถทำอย่างอื่นเป็นเลเยอร์บน FS ใด ๆ โดยพลการ

ฉันอ่านที่อื่น และ .. ไม่ใช่ไฟล์ในไดเรกทอรีอีกเช่นกัน ฉันแน่ใจว่ามีเหตุผลที่ดีสำหรับสิ่งเหล่านี้และสิ่งที่เราชอบ (เช่นความสามารถในการติดตั้งระบบไฟล์ NTFS) เป็นไปได้เพราะสิ่งต่าง ๆ แต่ความสง่างามของ UNIX บางอย่างในการนำไปใช้ มันเป็นประโยชน์เช่นความมีอยู่ทั่วไปและความอ่อนไหวที่ความสง่างามนี้มอบให้ซึ่งทำให้มันแข็งแกร่งและทนทานเป็นเวลาสี่ทศวรรษ ในขณะที่เราปล่อยการใช้งานที่สง่างามในที่สุดมันก็จะกลายเป็นเหมือน Windows (ฉันหวังว่าฉันผิด!) ใครบางคนจะสร้างระบบปฏิบัติการใหม่ซึ่งเป็นไปตามหลักการที่สง่างาม สิ่งที่ต้องคิด บางทีฉันผิดฉันไม่คุ้นเคย (ชัดเจน) กับการใช้งานในปัจจุบัน มันคือ น่าอัศจรรย์ แต่การเข้าใจอายุ 30 ปีนั้นใช้กับ Linux ได้อย่างไรส่วนใหญ่แล้ว!

— user57607
แหล่งที่มา

ฉันคิดว่าแม้ว่าฉันอาจจะผิดที่.และ..ไม่ได้เป็นฮาร์ดลิงก์ในระบบไฟล์สำหรับระบบไฟล์ที่ทันสมัย อย่างไรก็ตามโปรแกรมควบคุมระบบไฟล์ปลอม มันเป็นระบบไฟล์ที่หยุดการเชื่อมโยงไดเรกทอรีต่างๆ สำหรับระบบไฟล์เก่ามันเป็นไปได้ (แต่อันตราย) ในการทำสิ่งที่คุณพยายามมองmount --bindดูmount --make…และอาจจะเป็นตู้คอนเทนเนอร์

— ctrl-alt-delor

0

จากสิ่งที่ฉันรวบรวมเหตุผลหลักคือมันมีประโยชน์ที่จะสามารถเปลี่ยนชื่อไดเรกทอรีโดยไม่ทำให้โปรแกรมที่ใช้งานทำงานยุ่งเหยิงซึ่งใช้ไดเรกทอรีทำงานเพื่ออ้างอิงไฟล์อื่น ๆ สมมติว่าคุณกำลังใช้งานไวน์อยู่~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exeและคุณต้องการย้ายคำนำหน้าทั้งหมดไปไว้~/.wineแทน หากมีเหตุผลแปลก ๆ บางอย่างที่ Firefox กำลังเข้าถึงdrive_c/windowsโดยอ้างถึงการ../../windowsเปลี่ยนชื่อ~/.newwineprefixตัวแบ่งการใช้งานของ..ที่ติดตามไดเรกทอรีหลักเป็นสตริงข้อความแทน inode

การจัดเก็บ inode ของพาเรนต์ไดเร็กทอรีเดียวต้องง่ายกว่าการพยายามติดตามทุกพา ธ เป็นทั้งสตริงข้อความและชุดของ inodes

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

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

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

— มิซากิ
แหล่งที่มา