ทำไมฮาร์ดลิงก์ไม่ได้รับอนุญาตสำหรับไดเรกทอรี?


129

ฉันใช้ Ubuntu 12.04 เมื่อฉันพยายามสร้างฮาร์ดลิงก์สำหรับไดเรกทอรีใด ๆ มันจะล้มเหลว ฉันสามารถสร้างฮาร์ดลิงก์สำหรับไฟล์ที่อยู่ภายในขอบเขตของระบบไฟล์ ฉันรู้เหตุผลว่าทำไมเราไม่สามารถสร้างฮาร์ดลิงก์สำหรับไฟล์ที่นอกเหนือจากระบบไฟล์

ฉันลองคำสั่งเหล่านี้:

$ ln /Some/Direcoty /home/nischay/Hard-Directory
hard link not allowed for directory
$ sudo ln /Some/Direcoty /home/nischay/Hard-Directory
[sudo] password for nischay: 
hard link not allowed for directory

ฉันแค่ต้องการทราบเหตุผลที่อยู่เบื้องหลังนี้ มันเหมือนกันสำหรับ GNU / Linux distros และ Unix flavor ทั้งหมด (BSD, Solaris, HP-UX, IBM AIX) หรือเฉพาะใน Ubuntu หรือ Linux เท่านั้น



2
ลองln -F <src> <dst>และอาจใช้งานได้ แน่นอนว่ามันใช้งานได้กับ superuser ใน Unix เวอร์ชั่นเก่ากว่า ไม่มีใครจำได้ว่าเป็น UCB หรือ System V หรือไม่ ใช่สิ่งเลวร้ายอาจเกิดขึ้นได้ แต่โดยปกติจะไม่ ดังที่ฉันจำได้rmdirว่ารู้ว่าจะไม่ทำการลบฮาร์ดลิงก์ต่อไป อย่างไรก็ตามผู้ใช้อาจสับสนและลบสิ่งที่ผิดพลาด
Steve Pitchers

@StevePitchers สามารถrmdirจัดการกับฮาร์ดลิงก์ได้อย่างพิเศษได้อย่างไร? ฮาร์ดลิงก์เป็นเพียงลิงค์ปกติ แต่เป็นลิงค์เพิ่มเติม ไม่ง่ายเลยที่จะทราบว่ามีลิงก์พิเศษที่ผิดปกติอยู่หรือไม่โดยไม่ต้องมีการบันทึกเพิ่มเติม
Volker Siegel

1
แต่ละโหนดเก็บจำนวนฮาร์ดลิงก์ที่ชี้ไปที่: เนื้อหาจะถูกปล่อยออกมาเมื่อไม่มีการเชื่อมโยงเหลืออยู่เท่านั้น ดังนั้นrmdirสามารถบอกได้ว่าไดเรกทอรีมีลิงค์จากที่อื่นหรือไม่ การลบแบบเรียกซ้ำrm -rจะต้องเขียนด้วยความระมัดระวังเพื่อให้แน่ใจว่ามันจะทำงานได้อย่างถูกต้องแม้ว่าจะมีข้อผิดพลาดเช่น "สิทธิ์ถูกปฏิเสธ" BTW, UCB = BSD, doh!
Steve Pitchers

2
ฉันทำln -Fไดเรกทอรีและใช้งานได้แล้ว แต่คุณไม่กล้าลบไดเรกทอรีหลังจากนั้นเพราะกลัวว่าจะทำให้ระบบไฟล์เสียหาย
Edward Falk

คำตอบ:


159

ไดเรกทอรีฮาร์ดไดรฟ์แตกระบบไฟล์ในหลายวิธี

มันช่วยให้คุณสร้างลูปได้

ฮาร์ดลิงก์ไปยังไดเร็กทอรีสามารถลิงก์ไปยังพาเรนต์ของตัวเองซึ่งสร้างลูประบบไฟล์ ตัวอย่างเช่นคำสั่งเหล่านี้สามารถสร้างการวนซ้ำด้วยลิงก์ย้อนกลับl:

mkdir -p /tmp/a/b
cd /tmp/a/b
ln -d /tmp/a l

ระบบไฟล์ที่มีลูปไดเรกทอรีมีความลึกไม่ จำกัด :

cd /tmp/a/b/l/b/l/b/l/b/l/b

การหลีกเลี่ยงการวนซ้ำไม่สิ้นสุดเมื่อสำรวจโครงสร้างไดเรกทอรีนั้นค่อนข้างยาก (เช่น POSIX ต้องfindหลีกเลี่ยงปัญหานี้)

ระบบไฟล์ที่มีฮาร์ดลิงก์ประเภทนี้ไม่ได้เป็นต้นไม้อีกต่อไปเพราะต้นไม้จะต้องไม่มีลูป

พวกเขาทำลายความไม่น่าสงสัยของไดเรกทอรีหลัก

ด้วยลูประบบไฟล์มีไดเร็กทอรีพาเรนต์หลายไดเร็กทอรี:

cd /tmp/a/b
cd /tmp/a/b/l/b

ในกรณีแรกเป็นไดเรกทอรีแม่ของ/tmp/a ในกรณีที่สองเป็นไดเรกทอรีแม่ของซึ่งเป็นเช่นเดียวกับ ดังนั้นจึงมีสองไดเรกทอรีหลัก/tmp/a/b
/tmp/a/b/l/tmp/a/b/l/b/tmp/a/b

พวกเขาทวีคูณไฟล์

ไฟล์ถูกระบุโดยพา ธ หลังจากแก้ไข symlink ดังนั้น

/tmp/a/b/foo.txt
/tmp/a/b/l/b/foo.txt

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

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

ตัวอย่างของคุณ

$ ln /Some/Direcoty /home/nischay/Hard-Directory
$ echo foo > /home/nischay/Hard-Directory/foobar.txt
$ diff -s /Some/Direcoty/foobar.txt /home/nischay/Hard-Directory/foobar.txt
$ echo bar >> /Some/Direcoty/foobar.txt
$ diff -s /Some/Direcoty/foobar.txt /home/nischay/Hard-Directory/foobar.txt
$ cat /Some/Direcoty/foobar.txt
foo
bar

ซอฟต์ลิงค์ไปยังไดเรกทอรีสามารถทำงานได้อย่างไร?

พา ธ ที่อาจมีซอฟต์ลิงก์และแม้แต่ลูปไดเร็กทอรีซอฟต์ลิงก์ที่มักถูกใช้เพื่อระบุและเปิดไฟล์ มันสามารถใช้เป็นเส้นทางเชิงเส้นปกติ

แต่มีสถานการณ์อื่น ๆ เมื่อใช้เส้นทางเพื่อเปรียบเทียบไฟล์ ในกรณีนี้ลิงก์สัญลักษณ์ในพา ธ สามารถแก้ไขได้ก่อนแปลงเป็นขั้นต่ำและตกลงกันโดยทั่วไปในการสร้างพา ธ แบบบัญญัติ :

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

คำสั่งreadlinkสามารถแก้ไขพา ธ ไปยังพา ธ แบบบัญญัติ:

$ readlink -f /some/symlinked/path

ซอฟต์ลิงค์แตกต่างจากระบบไฟล์ที่ใช้

ซอฟต์ลิงค์ไม่สามารถทำให้เกิดปัญหาได้ทั้งหมดเพราะมันแตกต่างจากลิงค์ภายในระบบไฟล์ สามารถแยกความแตกต่างจากฮาร์ดลิงก์และแก้ไขไปยังพา ธ โดยไม่ต้องมีการเชื่อมโยงหากจำเป็น
ในบางแง่การเพิ่ม symlink ไม่ได้เปลี่ยนโครงสร้างระบบไฟล์พื้นฐาน - มันเก็บไว้ แต่เพิ่มโครงสร้างเพิ่มเติมเช่นชั้นแอปพลิเคชัน


จากman readlink:

 NAME
        readlink - print resolved symbolic links or canonical
        file names

 SYNOPSIS
        readlink [OPTION]... FILE...

 DESCRIPTION
        Print value of a symbolic link or canonical file name

        -f, --canonicalize
               canonicalize by  following  every  symlink  in
               every component of the given name recursively;
               all but the last component must exist
        [  ...  ]

1
ทำไมซอฟต์ลิงค์ถึงไม่ทำทั้งหมดนี้?
Tanay

1
@Tanay Right มันสามารถช่วยให้ Exposition เปรียบเทียบกับเคสที่คล้ายคลึงกันด้วยซอฟต์ลิงค์ ฉันจะพยายาม.
Volker Siegel

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

คำตอบที่ดี แต่แล้ว ... Apple ได้แก้ปัญหาเหล่านี้สำหรับ Time Machine อย่างไร
Damien

ฟังดูน่าสนใจมาก! แต่ฉันไม่รู้อะไรเลยว่าปัญหาคืออะไร - คุณสามารถบอกใบ้ให้ฉันได้หรือไม่?
Volker Siegel

77

"โดยทั่วไปคุณไม่ควรใช้ฮาร์ดลิงก์" อยู่ในวงกว้าง คุณต้องเข้าใจความแตกต่างระหว่างฮาร์ดลิงก์และ symlink และใช้แต่ละอย่างตามความเหมาะสม แต่ละชุดมีข้อดีและข้อเสีย:

Symlinks สามารถ:

  • ชี้ไปที่ไดเรกทอรี
  • ชี้ไปที่วัตถุที่ไม่มีอยู่จริง
  • ชี้ไปที่ไฟล์และไดเรกทอรีที่อยู่นอกระบบไฟล์เดียวกัน

ฮาร์ดลิงก์สามารถ:

  • เก็บไฟล์ที่พวกเขาอ้างอิงจากการถูกลบ

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

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


41
เกี่ยวกับย่อหน้าสุดท้ายหากคุณแก้ไขไฟล์ hardlinked ที่ "คัดลอก" ไฟล์ต้นฉบับก็จะเปลี่ยนไปเช่นกัน - ดูunix.stackexchange.com/questions/70531/…
marcin

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

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

3
Heck, symlink ไม่จำเป็นต้องชี้ไปที่อะไรเลย ln -s "Don't use this directory" READMEถูกต้องตามกฎหมาย ในความเป็นจริงถ้าคุณคิดเกี่ยวกับมันไดเรกทอรีสามารถใช้เป็นฐานข้อมูลเชิงสัมพันธ์และไม่มีไฟล์จริงใด ๆ เลย
Edward Falk

5
-1 สิ่งนี้ไม่ตอบคำถามและข้อมูลบางอย่างผิดปกติ
wjandrea

43

ปีงบประมาณคุณสามารถบรรลุสิ่งเดียวกันกับฮาร์ดไดรฟ์สำหรับไดเรกทอรีโดยใช้เมานต์:

mount -t bind /var/www /home/user/workspace/www

นี้เป็นอันตรายมากเพราะเครื่องมือส่วนใหญ่และโปรแกรมจะไม่ตระหนักถึงความผูกพัน rm -rf /home/userผมเคยทำอะไรบางอย่างเช่นในตัวอย่างข้างต้นแล้วดำเนินการต่อไป /var/wwwโชคดีที่มีอะไรที่เกี่ยวข้องอยู่ใน


6
mount --bind <src> <dest>ผมเคยใช้ ใช้ด้วยความระมัดระวังไม่ให้เช็ดsrc;)
kachar

1
ฉันได้รับ:mount: unknown filesystem type 'bind'
Wizek

4
ใน Busybox มันmount -o bind src dest
Mat M

@MatM เช่นเดียวกันกับ Debian
hanshenrik

2
หากคุณต้องการเมานต์เพื่ออ่านเท่านั้นคุณสามารถตั้งค่าการอนุญาตบนจุดเมานต์และหลีกเลี่ยงrm -rfปัญหา superuser.com/questions/320415/…
zanerock

19

เหตุผลที่ไม่อนุญาตให้มีการเชื่อมโยงไดเรกทอรีอย่างหนักเป็นเรื่องเทคนิคเล็กน้อย โดยพื้นฐานแล้วพวกเขาทำลายโครงสร้างของระบบไฟล์ โดยทั่วไปแล้วคุณไม่ควรใช้ฮาร์ดลิงก์ ลิงก์สัญลักษณ์อนุญาตการทำงานส่วนใหญ่โดยไม่ทำให้เกิดปัญหา (เช่นln -s target link)


17
ฮาร์ดลิงก์มีกรณีการใช้งานที่ดี การบอกว่าคุณไม่ควรใช้มันกว้างเกินไปสักหน่อย
Sander Steffann

4
+2 สำหรับการให้ลิงก์ที่ตอบคำถามของ OP (และของฉัน), -1 สำหรับเปล่งความคิดเห็น ("โดยทั่วไปคุณไม่ควรใช้ฮาร์ดลิงก์)" - หากมีลิงก์เพื่อสนับสนุนมันจะใช้ได้) ซึ่งเป็นสิ่งที่ดีเพราะฉันไม่สามารถให้ +2 ได้ ; D
msb

3
ลิงก์ "มันทำลายโครงสร้างระบบไฟล์" ไม่ทำงาน
Charlie Parker

5
พยายามสรุปเนื้อหาของลิงค์ในคำตอบและเก็บลิงค์ไว้เป็นข้อมูลอ้างอิง นี่เป็นวิธีปฏิบัติที่ดีในการแลกเปลี่ยน Stack เพื่อหลีกเลี่ยงการเชื่อมโยงเน่า
Oxwivi

3
ทำได้ดีมาก @ CharlieParker; ไม่ได้ตั้งใจที่ดีที่สุดความคิดเห็นแดกดันของทุกครั้ง :) (?)
Eliran มาลกา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.