ทำไมจึงเป็นไปได้ที่จะย้ายโปรแกรมที่กำลังทำงานอยู่ใน Ubuntu

24

ฉันเพิ่งรู้ว่าฉันสามารถย้ายโปรแกรมที่ใช้งานอยู่ไปยังไดเรกทอรีอื่น จากประสบการณ์ของฉันที่เป็นไปไม่ได้ใน MacOs หรือ Windows มันทำงานอย่างไรใน Ubuntu

แก้ไข: ฉันคิดว่ามันเป็นไปไม่ได้บน Mac แต่ดูเหมือนจะเป็นไปได้เมื่อยืนยันความคิดเห็น บางทีมันอาจเป็นไปไม่ได้บน Windows ขอบคุณสำหรับคำตอบทั้งหมด

kernel files directory

— n0.ob
แหล่งที่มา

2

สวยมากล่อข้ามไซต์: stackoverflow.com/a/196910/1394393

— jpmc26

1

คุณไม่สามารถrename(2)เรียกใช้งานปฏิบัติการได้บน OS X หรือไม่ เกิดอะไรขึ้นคุณได้EBUSYอะไรหรือเปล่า ทำไมมันไม่ทำงาน หน้า man เปลี่ยนชื่อ (2) ไม่ได้มีเอกสารETXTBUSYสำหรับการเรียกระบบนั้นและพูดถึงเพียงEBUSYว่าเป็นไปได้สำหรับการเปลี่ยนชื่อไดเรกทอรีดังนั้นฉันไม่ทราบว่าระบบ POSIX แม้จะไม่อนุญาตให้เปลี่ยนชื่อไฟล์ปฏิบัติการ

— Peter Cordes

3

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

— Constantino Tsarouhas

1

มันใช้งานได้จริงเมื่อ Linux ตั้งใจคุณควรรู้ว่าคุณกำลังทำอะไรอยู่ : P

— 59

2

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

— โทมัส

32

ขอผมทำลายมันหน่อย

เมื่อคุณเรียกใช้ไฟล์ปฏิบัติการลำดับของการเรียกระบบจะถูกดำเนินการโดยเฉพาะอย่างยิ่งfork()และexecve():

fork()สร้างกระบวนการลูกของกระบวนการเรียกซึ่งเป็นสำเนา (ส่วนใหญ่) ของพาเรนต์ที่แน่นอนทั้งสองยังคงเรียกใช้ไฟล์ปฏิบัติการเดียวกัน (โดยใช้เพจหน่วยความจำแบบคัดลอกตามการเขียนดังนั้นจึงมีประสิทธิภาพ) มันส่งคืนสองครั้ง: ในพาเรนต์จะส่งคืน PID ลูก ใน child มันจะคืนค่า 0 โดยปกติกระบวนการ child เรียก execve ทันที:
execve()ใช้เส้นทางแบบเต็มไปยังไฟล์ที่เรียกทำงานได้เป็นอาร์กิวเมนต์และแทนที่กระบวนการเรียกด้วยไฟล์ปฏิบัติการ ณ จุดนี้กระบวนการที่สร้างขึ้นใหม่จะได้รับพื้นที่ที่อยู่เสมือนของตนเองเช่นหน่วยความจำเสมือนและการดำเนินการเริ่มต้นที่จุดเริ่มต้น (ในสถานะที่ระบุโดยกฎของแพลตฟอร์ม ABI สำหรับกระบวนการใหม่)

ณ จุดนี้โหลดเดอร์ของเคอร์เนล ELF ได้แมปข้อความและส่วนข้อมูลของปฏิบัติการลงในหน่วยความจำราวกับว่ามันได้ใช้การmmap()เรียกของระบบ (ที่มีการแมปแบบอ่านอย่างเดียวและการอ่านเขียนส่วนตัวร่วมกันตามลำดับ) BSS นั้นจะถูกแมปเหมือนกับ MAP_ANONYMOUS (BTW ฉันไม่สนใจการเชื่อมโยงแบบไดนามิกที่นี่เพื่อความเรียบง่าย: ตัวเชื่อมโยงแบบไดนามิกopen()และmmap()ห้องสมุดแบบไดนามิกทั้งหมดก่อนที่จะข้ามไปยังจุดเข้าใช้งานของโปรแกรมหลัก

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

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

ทีนี้เรามาดูการเคลื่อนที่:

เมื่อคุณย้ายไฟล์ภายในระบบไฟล์เดียวกันการเรียกใช้ระบบที่ถูกเรียกใช้rename()งานซึ่งเพิ่งเปลี่ยนชื่อไฟล์เป็นชื่ออื่น inode ของไฟล์จะยังคงเหมือนเดิม

ในขณะที่ระบบไฟล์ต่างกันสองระบบเกิดขึ้นสองอย่าง:

เนื้อหาของไฟล์ที่คัดลอกไปยังตำแหน่งใหม่ก่อนโดยread()และwrite()
หลังจากนั้นไฟล์จะถูกยกเลิกการเชื่อมโยงจากไดเรกทอรีต้นทางโดยใช้unlink()และเห็นได้ชัดว่าไฟล์นั้นจะได้รับ inode ใหม่บนระบบไฟล์ใหม่

rmที่จริงแล้วคือunlink()การใช้ไฟล์ที่กำหนดจากแผนผังไดเรกทอรีดังนั้นการมีสิทธิ์ในการเขียนในไดเรกทอรีจะทำให้คุณมีสิทธิ์เพียงพอที่จะลบไฟล์ใด ๆ ออกจากไดเรกทอรีนั้น

ตอนนี้เพื่อความสนุกลองนึกภาพว่าจะเกิดอะไรขึ้นเมื่อคุณย้ายไฟล์ระหว่างสองไฟล์และคุณไม่ได้รับอนุญาตให้unlink()ใช้ไฟล์จากแหล่งที่มา

ไฟล์จะถูกคัดลอกไปยังปลายทางในตอนแรก ( read(), write()) จากนั้นunlink()จะล้มเหลวเนื่องจากการอนุญาตไม่เพียงพอ ดังนั้นไฟล์จะยังคงอยู่ในทั้งสองระบบไฟล์ !!

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

5

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

— jlliagre

@jlliagre แก้ไขแล้วฉันหวังว่ามันจะชัดเจนขึ้นแล้ว ขอบคุณ

— heemayl

6

คำสั่ง "กระบวนการไม่ได้ใช้ระบบไฟล์อีกต่อไป" ยังคงเป็นที่น่าสงสัย

— jlliagre

2

ความเข้าใจพื้นฐานว่าไฟล์ที่ระบุในระบบไฟล์ไม่ได้ระบุโดยตรงโดยชื่อไฟล์ควรมีความชัดเจนมากขึ้น

— Thorbjørn Ravn Andersen

2

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

— jlliagre

14

นั่นมันค่อนข้างตรงไปตรงมา ลองใช้ไฟล์ปฏิบัติการที่ชื่อ / usr / local / bin / whoopdeedoo นั่นเป็นเพียงการอ้างอิงถึงinode ที่เรียกว่า(โครงสร้างพื้นฐานของไฟล์บนระบบไฟล์ Unix) มันเป็นไอโหนดที่ทำเครื่องหมายว่า "ใช้งานอยู่"

ตอนนี้เมื่อคุณลบหรือย้ายไฟล์ / usr / local / whoopdeedoo สิ่งเดียวที่ถูกย้าย (หรือเช็ด) คือการอ้างอิงถึง inode ไอโหนดยังคงไม่เปลี่ยนแปลง แค่นั้นแหละ

ฉันควรตรวจสอบ แต่ฉันเชื่อว่าคุณสามารถทำได้บนระบบไฟล์ Mac OS X ด้วย

Windows ใช้แนวทางที่แตกต่าง ทำไม? ใครจะรู้...? ฉันไม่คุ้นเคยกับ internals ของ NTFS ในทางทฤษฎีระบบไฟล์ทั้งหมดที่ใช้การอ้างอิงถึงโครงสร้าง intenal สำหรับชื่อไฟล์ควรสามารถทำได้

ฉันยอมรับว่าฉันเข้าใจง่ายเกินไป แต่ไปอ่านหัวข้อ "ความหมาย" ใน Wikipedia ซึ่งทำได้ดีกว่าฉันมาก

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

1

ถ้าคุณใช้ทางลัดใน Windows เพื่อเริ่มการทำงานคุณสามารถล้างทางลัดได้เช่นกันถ้าคุณต้องการเปรียบเทียบมันแบบนั้น = 3

— เรย์

2

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

— jawtheshark

1

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

— Ruslan

13

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

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

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

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

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

1

นี้ไม่ถูกต้อง. execve()ไม่ส่งคืน FD ใด ๆ เพียงแค่เรียกใช้งานโปรแกรม ดังนั้นสำหรับตัวอย่างเช่นถ้าคุณเรียกใช้tail -f /foo.logแล้วของพวกเขาเป็น FD ( /proc/PID/fd/<fd_num>) ที่เกี่ยวข้องกับtailสำหรับfoo.logแต่ไม่ใช่สำหรับปฏิบัติการตัวเองtailไม่ได้อยู่ในปกครองของมันเช่นกัน สิ่งนี้เป็นจริงสำหรับ executables เดียวเช่นกัน

— heemayl

@ heemayl ฉันไม่ได้พูดถึงexecveดังนั้นฉันไม่เห็นว่าสิ่งนี้เกี่ยวข้องกันอย่างไร เมื่อเคอร์เนลเริ่มเรียกใช้งานไฟล์การพยายามแทนที่ไฟล์จะไม่แก้ไขโปรแกรมเคอร์เนลจะโหลดการแสดงผลจุดที่สงสัย หากคุณต้องการ "อัพเดท" ไฟล์ปฏิบัติการในขณะที่รันอยู่คุณสามารถโทรหาได้execveในบางจุดเพื่อให้เคอร์เนลอ่านไฟล์อีกครั้ง แต่ฉันไม่เห็นว่าเรื่องนี้เป็นอย่างไร ประเด็นคือ: การลบ "การเรียกใช้งานได้จริง" ไม่ได้เป็นการกระตุ้นให้เกิดการลบข้อมูลใด ๆ จนกว่าการปฏิบัติการจะหยุดลง

— Bakuriu

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

— heemayl

2

คุณไม่จำเป็นต้องใช้ตัวจัดการไฟล์เพื่อให้มีการอ้างอิงไปยังไฟล์ - การมีเพจที่แมปนั้นก็เพียงพอแล้ว

— Simon Richter

1

Unix ไม่มี "ตัวจัดการไฟล์" open()ส่งกลับไฟล์บ่งซึ่งเป็น heemayl execve()พูดคุยเกี่ยวกับที่นี่ด้วย ใช่กระบวนการทำงานมีการอ้างอิงถึงไฟล์เรียกทำงาน แต่นั่นไม่ใช่ตัวให้คำอธิบายไฟล์ อาจเป็นไปได้แม้ว่ามันจะmunmap()ทำการแมปไฟล์ทั้งหมดของมัน แต่ก็ยังคงมีการอ้างอิง (สะท้อนใน / proc / self / exe) ที่หยุดการทำงานของไอโหนด (สิ่งนี้อาจเป็นไปได้โดยไม่ล้มเหลวหากทำสิ่งนี้จากฟังก์ชั่นห้องสมุดที่ไม่เคยส่งคืน) BTW, การตัดหรือดัดแปลงไฟล์ปฏิบัติการที่ใช้งานอยู่อาจให้คุณETXTBUSYแต่อาจใช้งานได้

— Peter Cordes

7

ในระบบไฟล์ Linux เมื่อคุณย้ายไฟล์ตราบใดที่มันไม่ข้ามขอบเขตระบบไฟล์ (อ่าน: อยู่ในดิสก์ / พาร์ติชั่นเดียวกัน) สิ่งที่คุณกำลังเปลี่ยนคือ inode ของ..(พาเรนต์ไดเร็กทอรี) ไปยังตำแหน่งใหม่ . ข้อมูลจริงยังไม่ได้ย้ายเลยบนดิสก์เพียงตัวชี้เพื่อให้ระบบแฟ้มรู้ว่าจะหาได้ที่ไหน

นี่คือเหตุผลที่การดำเนินการย้ายทำได้อย่างรวดเร็วและเป็นไปได้ว่าทำไมไม่มีปัญหาในการย้ายโปรแกรมที่กำลังทำงานอยู่เนื่องจากคุณไม่ได้ย้ายโปรแกรมจริงๆ

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

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

— jlliagre

6

เป็นไปได้เพราะการย้ายโปรแกรมไม่ส่งผลกระทบต่อกระบวนการที่เริ่มต้นโดยการเรียกใช้งาน

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

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

โปรดทราบว่าการเรียกใช้โปรแกรมไม่ได้โหลดทุกอย่างพร้อมกันในหน่วยความจำ (กายภาพ) ในทางตรงกันข้ามโหลดขั้นต่ำที่เข้มงวดที่จำเป็นสำหรับกระบวนการเริ่มต้นเท่านั้นที่จะถูกโหลด จากนั้นเพจที่ต้องการจะโหลดตามความต้องการตลอดอายุการใช้งานของกระบวนการ สิ่งนี้เรียกว่าการเพจจิ้ง หากมีปัญหาการขาดแคลน RAM ระบบปฏิบัติการจะปล่อย RAM ค้างไว้ที่หน้าเหล่านี้ดังนั้นจึงเป็นไปได้ที่กระบวนการจะโหลดหน้าเว็บเดียวกันหลายครั้งจาก inode ที่เรียกใช้งานได้

สาเหตุที่เป็นไปไม่ได้ที่ Windows จะเริ่มต้นเนื่องจากระบบไฟล์พื้นฐาน (FAT) ไม่สนับสนุนแนวคิดแยกของรายการไดเรกทอรีเทียบกับ inodes ข้อ จำกัด นี้ไม่มีอยู่ใน NTFS อีกต่อไป แต่การออกแบบระบบปฏิบัติการได้ถูกเก็บรักษาไว้เป็นเวลานานทำให้ข้อ จำกัด ที่น่ารังเกียจต้องรีบูตเมื่อติดตั้งไบนารีเวอร์ชันใหม่ซึ่งไม่ใช่กรณีของ Windows รุ่นล่าสุด

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

1

ฉันเชื่อว่า Windows รุ่นใหม่กว่าสามารถใช้งานไบนารีโดยไม่ต้องรีบูตเครื่อง

— Thorbjørn Ravn Andersen

@ ThorbjørnRavnAndersenฉันสงสัยว่าทำไมการอัปเดตทั้งหมดยังต้องการการรีสตาร์ท :(

— Braiam

1

@Braiam พวกเขาทำไม่ได้ มองใกล้ ๆ แม้ว่าไบนารีสามารถอัพเดตเคอร์เนลไม่สามารถ (ตามความรู้ของฉัน) และต้องการให้รีบูตเพื่อแทนที่ด้วยเวอร์ชันที่ใหม่กว่า สิ่งนี้ใช้ได้สำหรับเมล็ดระบบปฏิบัติการส่วนใหญ่ คนฉลาดกว่าที่ฉันเขียน kpatch สำหรับ Linux ซึ่งสามารถแก้ไขเคอร์เนล Linux ในขณะที่ทำงาน - ดูen.wikipedia.org/wiki/Kpatch

— Thorbjørn Ravn Andersen

@ ThorbjørnRavnAndersenฉันหมายถึง "การปรับปรุง Windows ทั้งหมด"

— Braiam

@Braiam ใช่ - เป็นอย่างนั้น I. โปรดมองใกล้ ๆ

— Thorbjørn Ravn Andersen

4

โดยทั่วไปใน Unix และ ilk ชื่อไฟล์ (รวมถึงพา ธ ไดเร็กทอรีที่นำไปสู่) ใช้สำหรับเชื่อมโยง / ค้นหาไฟล์เมื่อเปิดไฟล์(การเรียกใช้ไฟล์เป็นวิธีหนึ่งในการเปิดไฟล์ในลักษณะ) หลังจากนั้นช่วงเวลานั้นตัวตนของไฟล์ (ผ่าน "inode") จะถูกสร้างขึ้นและไม่ได้ถูกถามอีกต่อไป คุณสามารถลบไฟล์เปลี่ยนชื่อเปลี่ยนการอนุญาต ตราบใดที่โพรเซสหรือพา ธ ของไฟล์มีหมายเลขอ้างอิงบนไฟล์ / inode มันก็จะวนไปมาเหมือนกับไพพ์ระหว่างกระบวนการต่างๆ (อันที่จริงแล้วในประวัติศาสตร์ UNIX ไพพ์นั้นเป็นไอโหนดนิรนามที่มีขนาดพอดีกับ "direct blocks" การอ้างอิงที่เก็บข้อมูลดิสก์ใน inode คล้ายกับ 10 blocks)

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

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

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

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