เหตุใดจึงมีการผสมผสานของ symlink และ hardlinks ใน / bin


10

ฉันเข้าใจความแตกต่างทางเทคนิคระหว่าง symlink และ hardlinks นี่เป็นคำถามเกี่ยวกับการใช้ในทางปฏิบัติโดยเฉพาะฉันอยากรู้ว่าทำไมทั้งสองถูกใช้ในสภาพที่คล้ายกัน: /binไดเรกทอรี

นี่คือรายการในระบบของฉัน:

~$ ls -lai /bin
total 10508
32770 drwxr-xr-x  2 root root    4096 Jun 14 11:47 .
    2 drwxr-xr-x 28 root root    4096 Sep  6 13:15 ..
  119 -rwxr-xr-x  1 root root  959120 Mar 28 22:02 bash
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bunzip2
  127 -rwxr-xr-x  1 root root 1832016 Nov 16  2012 busybox
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bzcat
 6191 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzcmp -> bzdiff
 5640 -rwxr-xr-x  1 root root    2140 Dec 15  2011 bzdiff
 5872 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzegrep -> bzgrep
 3520 -rwxr-xr-x  1 root root    4877 Dec 15  2011 bzexe
 6184 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzfgrep -> bzgrep
 5397 -rwxr-xr-x  1 root root    3642 Dec 15  2011 bzgrep
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bzip2
 2851 -rwxr-xr-x  1 root root   10336 Dec 15  2011 bzip2recover
 6189 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzless -> bzmore
 5606 -rwxr-xr-x  1 root root    1297 Dec 15  2011 bzmore

ฉันเยื้องลิงก์ไปยังไอโหนดเดียวกันเพื่อให้มองเห็นได้ดีขึ้น ดังนั้นจะ symlinks ใช้ในกรณีของbzcmp, bzegrep, bzfgrep, bzlessและ hardlinks ในกรณีของbzip2, bzcat, bunzip2?

พวกเขาทั้งหมดไฟล์ปกติ (ไม่ใช่ไดเรกทอรี) อยู่ภายในระบบไฟล์เดียวเป็นระบบสาธารณูปโภคและแม้กระทั่งการทำงานกับสิ่งเดียวกัน: เก็บถาวร bzip มีเหตุผลในการใช้ hardlinks / symlinks ในกรณีนี้โดยเฉพาะอย่างยิ่งประวัติศาสตร์หรือฉันหายไปบางสิ่งบางอย่าง?

ชี้แจงคำถามของฉัน:

ฉันไม่ได้ถามเกี่ยวกับ:

  • ความแตกต่างทางเทคนิคระหว่าง symlink และ hardlinks
  • ข้อได้เปรียบทางทฤษฎีและข้อเสียแต่ละข้อ

คำถามเหล่านี้ได้รับการแก้ไขในกระทู้อื่น ๆ ใน SO ฉันพยายามที่จะเข้าใจว่าทำไมการตัดสินใจที่แตกต่างกันได้เกิดขึ้นในบางกรณี: สำหรับกลุ่มของระบบสาธารณูปโภคที่เกี่ยวข้อง ในทางเทคนิคแล้วพวกเขาทั้งหมดอาจเป็น symlink หรือพวกเขาทั้งหมดอาจเป็น hardlink ทั้งสองตัวเลือกจะทำงานได้ (และในทั้งสองกรณีโปรแกรมยังสามารถหาวิธีเรียกใช้ผ่านargv[0]) ฉันต้องการที่จะเข้าใจเจตนาที่นี่หากมี

ที่เกี่ยวข้อง:


ฉันคิดว่ามันขึ้นอยู่กับผู้ดูแลแพ็คเกจที่จะตัดสินใจ ฉันเรียกใช้ gentoo และใน/binคอลัมน์ที่สามของฉันls -laiอยู่เสมอ1ดังนั้นจึงดูเหมือนว่าจะใช้ลิงก์นุ่ม ๆ เท่านั้น คุณใช้ distro อะไร
เล่นซ้ำ

ฉันใช้ Ubuntu 12.04
Dmitry Pashkevich

1
ได้อย่างรวดเร็วก่อนดูเหมือนจะเป็นกฎบางส่วนของประเภทนี้: "hardlinks สำหรับไบนารี symlinks สคริปต์ / ห่อ"
เตอร์

คำตอบ:


5

เหตุใดจึงต้องใช้ฮาร์ดลิงก์กับลิงก์สัญลักษณ์

มี 3 ข้อได้เปรียบหลักของการใช้ hardlinks ผ่านการเชื่อมโยงสัญลักษณ์ในสถานการณ์นี้

ลิงก์ถาวร

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

ลิงก์สัญลักษณ์

  1. ลิงก์ชี้ไปที่วัตถุ (ซึ่งจะชี้ไปที่ไอโหนด)
  2. พวกเขาสามารถขยายระบบไฟล์ในขณะที่ฮาร์ดลิงก์ไม่สามารถ

ข้อดีของการเชื่อมโยงโดยทั่วไป

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

สิ่งนี้ทำได้ด้วยเหตุผลหลายประการ นี่คือบางส่วนของสิ่งที่ชัดเจนมากขึ้น:

  1. ง่ายต่อการพัฒนาปฏิบัติการเดี่ยวมากกว่าหลาย ๆ
  2. ประหยัดเนื้อที่ดิสก์
  3. ปรับใช้ง่ายขึ้น

ทำไมทั้งสองถูกใช้งาน?

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

ในการดูFHS (มาตรฐานระบบลำดับชั้นของระบบแฟ้ม)แม้ระบุด้วยวิธีนี้ว่าสามารถเป็นได้

สิ่งที่สกัดมา

หาก / bin / sh ไม่ใช่เชลล์ Bourne จริงจะต้องเป็นลิงก์ที่ยากหรือเป็นสัญลักษณ์ไปที่คำสั่งเชลล์จริง

เหตุผลที่อยู่เบื้องหลังนี้เป็นเพราะ sh และทุบตีอาจไม่จำเป็นต้องทำงานในลักษณะเดียวกัน การใช้ลิงก์สัญลักษณ์ยังช่วยให้ผู้ใช้เห็นได้อย่างง่ายดายว่า / bin / sh ไม่ใช่เชลล์ Bourne จริง

...

...

หากมีโปรแกรม gunzip และ zcat อยู่จะต้องเป็นลิงก์หรือสัญลักษณ์ไปยัง gzip อย่างหนัก / bin / csh อาจเป็นลิงก์สัญลักษณ์ไปยัง / bin / tcsh หรือ / usr / bin / tcsh

อ้างอิง


ใช่ฉันเข้าใจว่าขอบคุณ แต่ทำไมบางครั้งมีการใช้ symlink และบางครั้งใช้ hardlinks สิ่งที่คุณอธิบายจะใช้วิธีเดียวกันในทั้งสองกรณี
Dmitry Pashkevich

@DmitryPashkevich - ตกลงฉันได้สร้างคำตอบใหม่อีกครั้งโปรดแจ้งให้เราทราบหากดีกว่านี้
slm

บางทีฉันอาจจะถามคำถามที่โง่ แต่ฉันรู้สึกว่ามันยังไม่ได้รับคำตอบ :) ใช่ฉันคุ้นเคยกับความแตกต่างด้านเทคนิคและข้อดี / ข้อเสียของลิงก์ทั้งสองชนิด ฉันกำลังพยายามทำความเข้าใจกับกรณีเฉพาะ: เหตุใดฉันจึงเห็นทั้งฮาร์ดลิงก์และ symlink ใน/bin/ไดเรกทอรีของฉัน ทำไมนักพัฒนาของยูทิลิตี้เหล่านี้ไม่ยึดติดกับลิงค์ประเภทเดียว?
Dmitry Pashkevich

แก้ไขคำถามเดิมของฉันเพื่อ (หวังว่า) ชี้แจง
Dmitry Pashkevich

@DmitryPashkevich - เพิ่มเนื้อหาเพิ่มเติมบางส่วน แจ้งให้เราทราบหากช่วยได้
slm

5

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

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

โดยส่วนตัวแล้วฉันชอบที่จะใช้ symlink เสมอเพราะฉันยินดีจ่ายค่าโสหุ้ยเล็ก ๆ ของพวกเขาเพื่อแลกกับธรรมชาติของการทำเอกสารด้วยตนเอง

ผู้พัฒนารายอื่นจะเลือกฮาร์ดลิงก์สำหรับประสิทธิภาพเล็ก ๆ ที่พวกเขามีให้

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


1
ขอบคุณที่แบ่งปันมุมมองของคุณ! ฉันคิดว่าลักษณะ "การจัดทำเอกสารด้วยตนเอง" ของ symlinks เป็นสิ่งที่มักถูกมองข้าม
Dmitry Pashkevich
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.