สถานการณ์จำลอง - ลิงก์สัญลักษณ์หรือจุดเชื่อมต่อระบบไฟล์ NTFS

17

ความแตกต่าง

┌───────────────┬──────────┬──────────┬──────┬──── ───────┬─────┐
││สัมบูรณ์│สัมพัทธ์│ไฟล์│ไดเรกทอรี│ UNC │
├───────────────┼──────────┼──────────┼──────┼──── ───────┼─────┤
│ลิงก์สัญลักษณ์│ใช่│ใช่│ใช่│ใช่│ใช่│
unction จังค์ชัน│ใช่│ - │ - │ใช่│ - │
└───────────────┴──────────┴──────────┴──────┴──── ───────┴─────┘

สถานการณ์

สมมติว่าเรากำลังสร้างจุดแยกวิเคราะห์ใหม่เพื่อสร้างการเปลี่ยนเส้นทาง C:\SomeDir => D:\SomeDir

เนื่องจากสถานการณ์นี้ต้องการเส้นทางโลคัลเส้นทางแบบสัมบูรณ์เท่านั้นจึงอาจเป็นทางแยกหรือ symlink ในสถานการณ์นี้มีข้อได้เปรียบในการใช้อย่างใดอย่างหนึ่งหรือไม่?

สมมติว่า Windows 7 สำหรับระบบปฏิบัติการโดยไม่คำนึงถึงความเข้ากันได้แบบย้อนหลัง (ก่อน Vista, symlink ไม่ได้รับการสนับสนุนอย่างเป็นธรรมชาติแม้ว่าจะมีไดรเวอร์ของบุคคลที่สามที่ให้การสนับสนุน symlink ใน Windows XP)

ปรับปรุง

ฉันพบความแตกต่างอื่น

Symbolic Link - การอนุญาตของลิงก์จะมีผลต่อการดำเนินการลบ / เปลี่ยนชื่อบนลิงก์เท่านั้นการเข้าถึงแบบอ่าน / เขียน (ไปยังเป้าหมาย) อยู่ภายใต้การอนุญาตของเป้าหมาย
จังค์ชัน - สิทธิ์ของจังก์ชันมีผลต่อการแจงนับการเพิกถอนสิทธิ์บนทางแยกจะปฏิเสธรายชื่อไฟล์ผ่านทางแยกนั้นแม้ว่าโฟลเดอร์เป้าหมายจะมี ACL ที่อนุญาตมากกว่า

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

อัปเดต 2

Windows 8.1 จะแก้ไขลิงก์ไดเรกทอรีสัญลักษณ์เมื่อนำทางไปยังลิงก์สัญลักษณ์ผ่านกล่องข้อความในSave As...กล่องโต้ตอบ ทางแยกจะไม่ขยาย

คุณมีลิงค์ไปยังข้อมูลส่วนต่างของการอนุญาตหรือไม่ นั่นคือการค้นหาที่ค่อนข้าง

— surfasb

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

— Harry Johnston

@HarryJohnston: เริ่มแรกฉันสงสัยว่ามีความไม่สอดคล้องกันบ้างในขณะที่ฉันบล็อกการลบและเขียนสิทธิ์ในการ juctions แต่รายการและโฟลเดอร์ย่อยที่อยู่ด้านล่างทำได้ดี

— surfasb

ฉันจะไม่ตอบคำถามนี้อย่างเต็มที่เว้นแต่จะได้รับการร้องขอ แต่หากคุณใช้ GNU หรือระบบอื่นที่ไม่ใช่ Windows เพื่อเข้าถึงไดรฟ์ผ่านทางmount.cifssymlinks จะปรากฏขึ้นเช่นนี้ส่วน junctions จะถูกมองว่าเป็นไดเรกทอรีปกติ - อาจเป็นเพราะ จุดที่ความละเอียดของ IO เกิดขึ้นเช่นในเครื่องบนโฮสต์ Windows

— can-ned_food

4

ฉันเข้าใจลิงก์สัญลักษณ์ของ NTFS เพื่อใช้แทน Junctions บนระบบปฏิบัติการ Windows รุ่นใหม่ (Vista / 7/8) เนื่องจากทำงานในลักษณะเดียวกัน แต่ยังมีฟังก์ชันการทำงานเพิ่มเติม (จุดระยะไกล) ดังนั้นหากคุณทำงานกับระบบปฏิบัติการรุ่นใหม่แล้วไม่มีเหตุผลที่จะไม่ใช้ตัวเลือกลิงก์สัญลักษณ์

— การ์เร็ต
แหล่งที่มา

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

— Harry Johnston

2

ฉันคิดว่าจุดเชื่อมต่อนั้นรองรับซอฟต์แวร์สำรองได้มากกว่าลิงก์สัญลักษณ์ คุณควรตรวจสอบกับโปรแกรมสำรองใด ๆ ที่คุณใช้คุณสมบัติที่สนับสนุน

หากไม่ได้รับการสนับสนุนจุดเชื่อมต่อ / จุดแยกอาจถูกสำรองข้อมูลเป็นไดเรกทอรีแยกต่างหาก (และเรียกคืนเช่นนี้) หรือไม่สำรองข้อมูลเลย

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

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

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

— surfasb

2

@surfasb: อย่างไรก็ตามหาก symlink ไม่ได้รับการสนับสนุนเป็นพิเศษ (และได้รับการยอมรับเช่นนั้น) พวกเขาจะไม่ถูกสร้างขึ้นใหม่เป็น symlink ระหว่างการกู้คืนจากการสำรองข้อมูล

— haimg

อ่าจุดดีมาก! ฉันไม่ได้คิดล่วงหน้าไกลพอ

— surfasb

เท่าที่ฉันทราบนี่เป็นสิ่งสำคัญกว่าหากระบบปฏิบัติการ Windows รุ่นเก่าสามารถเข้าถึงไดรฟ์ข้อมูลได้

— can-ned_food

1

จุดเชื่อมต่อ NTFS สามารถชี้ไปยังไดเรกทอรีได้ในขณะที่ symlink ยังทำงานกับไฟล์ได้ด้วย

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

แต่สำหรับไฟล์คุณสามารถใช้ hardlink แทน

— Paradroid

0

นี่คือความแตกต่างอย่างหนึ่งที่ฉันสังเกตเห็น:

ฉันมีไดเรกทอรีที่ซิงค์ของสคริปต์แอพพกพา ฯลฯ ฉันใช้สคริปต์ชุดเพื่อสร้าง Junction ในไดเรกทอรีเมนูเริ่มซึ่งชี้ไปที่ไดเรกทอรีของทางลัดสำหรับแอพพกพา

ทางแยกอนุญาตให้ทางลัดปรากฏในเมนูเริ่ม เมื่อฉันใช้ Symbolic Link แทนจะไม่ทำงาน

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

แปลกมันใช้งานได้ดีสำหรับฉัน ฉันยังมี symlinks สำหรับแฟลชไดรฟ์ที่เสียบเข้ากับเครื่องของฉัน

— surfasb

@surfasb: คุณแน่ใจหรือว่าคุณกำลังทำสิ่งที่ฉันอธิบาย? ทางลัดภายในไดเรกทอรีที่ชี้ไปตามลิงก์สัญลักษณ์พร้อมกับไดเรกทอรีเมนูเริ่มไม่ปรากฏในเมนูเริ่มของฉัน พวกเขาทำเมื่อใช้ Junction แทน

— Paradroid

ไม่แน่ใจว่าฉันอ่านถูกต้องหรือไม่ ดังนั้นในเมนูเริ่ม symlink ที่ชี้ไปยังโฟลเดอร์ที่มีทางลัด? ฉันลองตอนนี้ ฉันยังมี symlink ให้ชี้ไปที่ symlink อื่นบนเส้นทาง unc ที่ชี้ไปยังโฟลเดอร์บนเส้นทาง UNC ด้วยทางลัด แน่นอนว่าทางลัด แต่การสำรวจเส้นทาง symlink "ระยะไกลถึงระยะไกล" จะถูกปิดใช้งานตามค่าเริ่มต้นใน Windows

— surfasb

0

บางทีฉันอาจพลาดความเห็นไปบ้าง แต่ความแตกต่างที่สำคัญอย่างหนึ่งระหว่าง symlink และ junctions ใน Windows สำหรับฉันคือสิทธิ์ที่จำเป็นในการสร้างทั้งสองอย่าง ในขณะที่ symlink เป็นค่าเริ่มต้นที่สามารถสร้างได้โดยใช้สิทธิ์พิเศษที่ผู้ใช้ไม่ได้มีเท่านั้น แต่สามารถสร้าง junctions ได้อย่างง่ายดายโดยผู้ใช้ที่เป็นค่าเริ่มต้นทั้งหมด OOB และเป็นประเภทลิงก์ที่ฉันต้องการสำหรับ dirs

โดยค่าเริ่มต้นสมาชิกของกลุ่มผู้ดูแลระบบมีสิทธิ์นี้

https://docs.microsoft.com/en-us/windows/device-security/security-policy-settings/create-symbolic-links

— Thorsten Schöning
แหล่งที่มา