Windows รู้จักลิงก์สัญลักษณ์ของ Linux หรือไม่


14

ฉันแค่สงสัยว่าระบบ Windows จัดการกับลิงก์สัญลักษณ์อย่างไร การเดาที่ดีที่สุดของฉันคือมันจะไม่รู้จักพวกเขา แต่ฉันไม่แน่ใจทั้งหมด

นอกจากนี้ Macs ต้องทำอย่างไรเมื่อเผชิญหน้ากับสิ่งใด?


1
คุณวางแผนที่จะเปิดเผย Windows ให้เป็นลิงค์สัญลักษณ์อย่างไร ไม่เข้าใจระบบไฟล์ที่รองรับ (ยกเว้น NTFS ซึ่งมีบางอย่างที่ไม่เหมือนลิงก์สัญลักษณ์ที่ซ่อนอยู่จาก UI)
Gilles 'ดังนั้นหยุดความชั่วร้าย'

โอ้ .. แล้วจะเกิดอะไรขึ้นถ้าคุณติดตั้งพาร์ติชั่น Windows ของคุณและพยายามใส่ลิงค์สัญลักษณ์เข้าไป มันใช้งานได้เหมือนเป็นโฟลเดอร์หรือไม่? (ถ้าเป็นเช่นนั้นฉันสงสัยว่าเกิดอะไรขึ้นกับ RECURSION ... )
JamesTheAwesomeDude

คุณช่วยฉันได้ไหม: stackoverflow.com/questions/21403772/…
Goofy

คำตอบ:


10

ขึ้นอยู่กับรุ่น Windows และการกำหนดค่าฝั่งเซิร์ฟเวอร์เมื่อเราพูดถึงดิสก์ที่ไม่ได้อยู่ในเครื่อง

ตั้งแต่ Windows Vista Windows มีแนวคิดเกี่ยวกับลิงก์สัญลักษณ์ แต่ความหมายแตกต่างกัน แต่ปัญหาที่สำคัญยิ่งกว่าที่นี่ควรเป็นชื่อพา ธ ซึ่งตามด้วยไวยากรณ์ที่แตกต่าง สำหรับผู้เริ่มต้น: แผนผังไดเรกทอรีรากเดียวที่ด้าน unixoid และตัวอักษรไดรฟ์หลายตัวเป็นรากด้าน Windows

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

ประเด็นหลักคือไม่ว่าจะเป็นไดรเวอร์ระบบไฟล์ - เมื่อเรียกใช้ในเครื่อง - จะทำการปรับเปลี่ยนเส้นทางที่ Windows ได้รับเพื่อดู ในกรณีเช่นนี้มันจะใช้งานได้กับ symlink ท้องถิ่น / สัมพัทธ์บางตัว สำหรับเส้นทางที่แน่นอนในฐานะเป้าหมายสิ่งต่าง ๆ จะยากและเป็นไปไม่ได้ที่จะอนุมานความหมายที่แท้จริง เหมือนกันสำหรับลิงก์ symlinks ระยะไกล (ถึง "แชร์เครือข่าย")

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


พิจารณาจุดเชื่อมต่อด้าน Linux:

/dev/sda1 /
/dev/sda2 /home
/dev/sda3 /var

และตอนนี้พิจารณา symlink ชี้ไปที่/home/paul/fstab /etc/fstabพวกเขาจะอยู่ในสองไดรฟ์ที่แตกต่างกันซึ่ง Windows - หากสามารถมองเห็นพวกเขาผ่านโปรแกรมควบคุมระบบไฟล์ (ซึ่งทำงาน!) - ไม่สามารถบอกได้ว่าเป็นของกันด้วยวิธีการ/etc/fstabอธิบาย ดังนั้นการเชื่อมโยงที่ Windows จะเห็นภายใต้โฟลเดอร์\paul\fstabแม้ว่าแปลจะชี้ไปที่ไม่ได้อยู่ใน\etc\fstab /dev/sda2และถ้า symlink นั้นชี้ไปที่เส้นทางสัมพัทธ์../../etc/fstabสิ่งต่าง ๆ จะไม่เปลี่ยนแปลงเลย


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


2
ว้าวนี่เป็นคำตอบที่ละเอียดและละเอียดมาก! ขอบคุณที่ให้ข้อมูลทั้งหมดนี้! ที่จริงแล้วฉันไม่รู้เลยว่า symlink ของ Linux นั้นเป็นแบบข้อความ ขอบคุณอีกครั้งสำหรับข้อมูลที่มีประโยชน์ทั้งหมดที่นี่
JamesTheAwesomeDude

คุณช่วยฉันได้ไหม: stackoverflow.com/questions/21403772/…
Goofy

ฉันคิดว่าฉันได้ทำ sym-link บน XP แล้วคุณแน่ใจหรือว่า vista เป็นคนแรก?
ctrl-alt-delor

ntfsรองรับจุดเชื่อมต่อ (สำหรับถ้าคุณไม่ชอบตัวอักษรเหล่านั้นทั้งหมด)
ctrl-alt-delor

@ Richard: ในความเป็นจริงจุดเมานต์ปริมาณเป็นศัพท์เทคนิคสำหรับสิ่งที่คุณเห็นเป็นตัวอักษรไดรฟ์ในระบบย่อย Win32 อย่างไรก็ตามคุณมีสิทธิ์ในการตั้งค่าระดับเสียงที่เมาท์บนโฟลเดอร์ที่มีอยู่ (ซึ่งคล้ายกับจุดเชื่อมต่อมาก) คุณลักษณะทางเทคนิคที่ใช้ในการดำเนินการไดรฟ์ข้อมูลจุดจุดเชื่อมต่อและการเชื่อมโยงสัญลักษณ์ที่เรียกว่าจุดแยกวิเคราะห์ใหม่ และใช่ Vista เป็นคนแรกที่ได้รับการสนับสนุนลิงค์สัญลักษณ์ บน XP คุณสามารถทำได้เฉพาะในระบบย่อยอื่น (เช่น POSIX) ซึ่งมีความหมายต่างกันเช่นด้านบน
0xC0000022L

2

คำตอบของ 0xC0000022L นั้นละเอียดสำหรับด้านต่าง ๆ ของ Windows Mac สามารถจดจำ symlink ของ Linux ได้ อย่างไรก็ตามลีนุกซ์ไม่สามารถจำแนกนามแฝงที่ทำใน Finder ของ Mac ได้ (symlink ที่สร้างโดยใช้ ln -s ทำงานได้ดี)


ดูเหมือนว่าชื่อแทนจะเป็น OSX คู่กับทางลัดบน Windows ( .lnkไฟล์)
0xC0000022L
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.