ความท้าทายของ Kernighan และ Pike: การใส่เครื่องหมายทับในชื่อไฟล์อย่างไร?


23

ฉันเพิ่งพบคำถามต่อไปนี้ในUnix Programming Environmentหนังสือคลาสสิคของ Kernighan และ Pike ใน Unix (ฉันพบข้อความด้านล่างในหน้า 79 ของปี 1984 ฉบับที่ ISBN: 0-13-937699-2):

แบบฝึกหัดที่ 3-6 (คำถามเคล็ดลับ) คุณจะทำให้ a / เป็นชื่อไฟล์ได้อย่างไร (เช่น a / ที่ไม่แยกส่วนประกอบของเส้นทาง)

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

ฉันเข้าใจว่า Linux ≠ Unix แต่ควรใช้หลักการเดียวกันเนื่องจากระบบจะต้องสามารถแยกลำดับชั้นไดเรกทอรีออกจากเส้นทางได้อย่างไม่น่าสงสัย

มีใครรู้บ้างว่า Kernighan และ Pike คิดอย่างไรเมื่อถามคำถามนี้ คำตอบที่ควรคืออะไร อะไรคือ 'เคล็ดลับ'? หรืออาจเป็นระบบ Unix ดั้งเดิมที่อนุญาตให้หนีเฉือนนี้ได้

UPD:

ฉันติดต่อ Brian Kernighan เกี่ยวกับคำถามและนั่นคือสิ่งที่เขาตอบ:

คำตอบคือ (หรือเคย)“ คุณทำไม่ได้”

ดังนั้นทิโมธีมาร์ตินพูดถูกและได้รับเครื่องหมายสีเขียว


3
ที่เกี่ยวข้อง (ไม่ซ้ำกัน) กรณีที่มีคนจัดการจริง: วิธีการลบไฟล์ชื่อ“ filen / ame” (มีเครื่องหมายทับ) บนระบบไฟล์ ext4 ใน debugfs?
Michael Homer


อืมมม บางทีคุณอาจสร้างไฟล์ที่มีตัวพิมพ์เล็กaและบังคับให้ระบบคิดว่าระบบไฟล์นั้นอยู่ในโลแคล EBCDIC หรือไม่? ASCII aคือ 0x61 ซึ่งสอดคล้องกับ/ใน EBCDIC (หน้ารหัส 37)
Fox

หนังสือเองบอกว่าเป็นคำถามลวงหรือไม่? ถ้าเป็นเช่นนั้นฉันคิดว่าค่อนข้างยืนยันว่าคุณจะไม่สามารถหาวิธีการออกแบบโดยทิ้งความคิดนอกกรอบที่คุณระบุไว้แล้ว
ilkkachu

คำตอบ:


12

บางทีคำตอบอาจเหมือนกับส่วนหนึ่งของคำตอบในคำถามเคล็ดลับนี้:
คุณลงช้างได้อย่างไร? คุณทำไม่ได้ คุณได้รับจากห่าน

จาก "การฝึกเขียนโปรแกรม" โดย Brian W. Kernighan และ Rob Pike, Ch. 6, pg. 158:

เมื่อ Steve Bourne เขียน Unix shell ของเขา (ซึ่งรู้จักกันในชื่อ Bourne shell) เขาสร้างไดเร็กตอรี่ของไฟล์จำนวน 254 ไฟล์ด้วยชื่อหนึ่งตัวอักษร, หนึ่งตัวสำหรับแต่ละค่าไบต์ยกเว้น '\ 0' และเครื่องหมายสแลช, อักขระสองตัวที่ ไม่สามารถปรากฏในชื่อไฟล์ Unix


3
ขอบคุณที่สอนเรื่องตลกให้ฉัน มันอาจจะทำหน้าที่เป็นแบบทดสอบความคล่องแคล่วภาษาอังกฤษ (ซึ่งฉันเพิ่งล้มเหลว)
firegurafiku

คุณพูดถูก ดู UPD
firegurafiku

1
@firegurafiku อธิบายโจ๊ก
ไอแซ

5

ฉันทำสิ่งนี้แล้ว นี่เป็นระบบ UNIX ที่ทำงานบน PDP-11 ประมาณปี 1980 ฉันสร้างไฟล์ชื่อ "WhatXNow?" จากนั้นฉันใช้ไฟล์ "editor" แบบไบนารีเพื่อแก้ไขอุปกรณ์ดิสก์และเปลี่ยน "X" เป็น "/" ใน inode (พร้อมระบบไฟล์ที่ไม่ได้ต่อเชื่อม)

เหยื่อไม่เคยรู้วิธีที่จะลบมัน

แก้ไข: อ๊ะ Barmar ถูกต้องฉันไม่เห็นบรรทัดที่นั่นเกี่ยวกับการไม่แก้ไขอุปกรณ์ และใช่มันเป็นไดเรกทอรีที่ฉันแก้ไขไม่ใช่ไอโหนด สักพักหนึ่ง :-)


1
ชื่อไฟล์ไม่ได้อยู่ใน inode แต่จะอยู่ในไฟล์พิเศษของไดเรกทอรี
Barmar

1
ฉันสงสัยว่าfsckจะลบออกแล้ว
Barmar

1
คำถามบอกว่าคุณสามารถแก้ไขระบบไฟล์ของคุณผ่านการบล็อกการเข้าถึงอุปกรณ์หรือใช้อักขระที่มีลักษณะคล้ายกันจาก Unicode แต่สิ่งเหล่านี้ไม่ใช่วิธีแก้ปัญหา นั่นไม่ใช่สิ่งที่คุณกำลังอธิบายในคำตอบของคุณ?
Barmar

@Barmar: อืมฉันอาจจะคิดถึงคำถามและการแก้ไขระบบไฟล์เป็นวิธีแก้ปัญหาที่มีความหมายเหรอ? ฉันไม่รู้
firegurafiku

ฉันเดิมพันนี่คือคำตอบ ฉันจำได้เมื่อคุณสามารถอ่านไดเรกทอรี บางทีทุกวัยที่ผ่านมารูทสามารถเขียนได้
Joshua

1

สถานการณ์ใด ๆ ที่/(อย่างแม่นยำยิ่งขึ้นไบต์ไม่ใช่ตัวอักษร - ด้วยค่า 0x2f; เกือบทั้งหมดเมล็ด Unix โดยเจตนาลบเลือนการเข้ารหัสอักขระ) ค้นหาวิธีการในการเข้าสู่รายการไดเรกทอรีโดยไม่ต้องบล็อกดิสก์ดิบที่ได้รับการจัดการด้วยมือ ข้อผิดพลาดในเคอร์เนล

ข้อผิดพลาดดังกล่าวเกิดขึ้นเป็นครั้งคราว กรณีหนึ่งที่ฉันจำได้ว่ากำลังอ่านบันทึกย่อของแพตช์นั่นคือการทำซ้ำยุค 1990 ของ ... ฉันอยากจะบอกโซลาริส แต่นั่นอาจผิด ... เสนอเซิร์ฟเวอร์สำหรับ AppleTalk Filing Protocol (AFP) ซึ่งเทียบเท่ากับ NOS แบบดั้งเดิมของ MacOS . ปัญหาคือใน MacOS แบบคลาสสิกคุณได้รับอนุญาตให้ใส่/องค์ประกอบชื่อพา ธได้อย่างสมบูรณ์ ตัวคั่นไดเรกทอรี:แทน เซิร์ฟเวอร์ AFP ควรทำสิ่งที่เทียบเท่าทางศีลธรรมtr :/ /:เมื่อทำการแมปชื่อพา ธ ที่ส่งโดยลูกค้าไปยังไฟล์บนดิสก์ แต่พวกเขาพลาดเส้นทางรหัสคู่และเนื่องจากเซิร์ฟเวอร์ถูกนำไปใช้ภายในเคอร์เนลจึงสามารถเขียนรายการไดเรกทอรีที่ไม่ถูกต้องได้

(ดูcomp.unix คำถามที่พบบ่อย # 2.2 , ส่วนย่อยเริ่มต้น "จะเกิดอะไรขึ้นถ้าชื่อไฟล์มี '/' อยู่ในนั้น?", สำหรับเวอร์ชันที่สูงกว่าของด้านบน)

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