บล็อกควบคุมไฟล์

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

FCB มีต้นกำเนิดมาจากCP/Mและมีอยู่ในDOS เวอร์ชันส่วนใหญ่เช่นกัน แม้ว่าจะใช้เป็นมาตรการเพื่อความเข้ากันได้กับเวอร์ชันเก่าในMS-DOSเวอร์ชัน 2.0 และเวอร์ชันต่อมาเท่านั้น FCB เต็มรูปแบบมีความยาว 36 ไบต์ ในเวอร์ชันแรกๆ ของ CP/M มีความยาว 33 ไบต์ ขนาดคงที่นี้ ซึ่งไม่สามารถเพิ่มได้โดยไม่ทำให้ความเข้ากันได้ของแอปพลิเคชันเสียหาย นำไปสู่การที่ FCB หมดความสำคัญในฐานะวิธีการมาตรฐานในการเข้าถึงไฟล์ในที่สุด

ความหมายของฟิลด์หลายฟิลด์ใน FCB แตกต่างกันระหว่าง CP/M และ DOS และยังขึ้นอยู่กับการดำเนินการที่กำลังดำเนินการอยู่ด้วย ฟิลด์ต่อไปนี้มีความหมายที่สอดคล้องกัน: ^{[ 1 ]}

ฟิลด์ความยาว 20 ไบต์ที่เริ่มต้นที่ออฟเซ็ต 0x0C ประกอบด้วยฟิลด์ซึ่ง (รวมถึงฟิลด์อื่นๆ) ให้ข้อมูลเพิ่มเติมเกี่ยวกับไฟล์: ^{[ 2 ]}

ค่าเพิ่มเติมถูกใช้โดย DOS เวอร์ชันใหม่กว่า จนกระทั่งข้อมูลใหม่ไม่สามารถบรรจุลงใน 20 ไบต์นี้ได้อีกต่อไป ไบต์ "ออฟเซ็ตลบ" บางส่วนก่อนหน้านี้ถูกบีบจากพื้นที่ที่สงวนไว้ใน CP/M Zero Page และ DOS Program Segment Prefixสำหรับการจัดเก็บคุณลักษณะของไฟล์^{[ 1 ]}

ใน CP/M, 86-DOSและPC DOS 1.x/MS-DOS 1.xx นั้น FCB เป็นวิธีเดียวในการเข้าถึงไฟล์ ภายใต้ DOS ฟังก์ชันย่อย INT 21h บางส่วนได้จัดเตรียมอินเทอร์เฟซเพื่อดำเนินการกับไฟล์โดยใช้ FCB ^{[ 1 ] [ 3 ] [ 4 ]}เมื่อมีการเตรียมการใน MS-DOS 2 เพื่อรองรับกระบวนการหรือผู้ใช้หลายคน^{[ 3 ] [ 4 ]}การใช้ระบบไฟล์อื่น^{[ 3 ] [ 4 ]}นอกเหนือจาก FAT หรือการแชร์ไฟล์^{[ 4 ]}ผ่านเครือข่ายในอนาคต FCB ถูกมองว่ามีขนาดเล็กเกินไปที่จะจัดการกับข้อมูลเพิ่มเติมที่จำเป็นสำหรับคุณสมบัติดังกล่าว^{[ 4 ]}ดังนั้น FCB จึงถูกมองว่าไม่เพียงพอสำหรับเส้นทางการขยายตัวในอนาคตต่างๆ^{[ 3 ]}นอกจากนี้ยังไม่มีฟิลด์สำหรับระบุไดเร็กทอรีย่อย^{[ 3 ]}การเปิดเผยข้อมูลที่เกี่ยวข้องกับระบบไฟล์ไปยังพื้นที่ผู้ใช้ยังถูกมองว่าเป็นความเสี่ยงด้านความปลอดภัยอีกด้วย^{[ 4 ]} FCB จึงถูกแทนที่ด้วยแฮนเดิลไฟล์ดังที่ใช้ในUNIXและระบบปฏิบัติการที่พัฒนาต่อยอดจาก UNIX ^{[ 3 ]}แฮนเดิลไฟล์เป็นเพียงตัวเลขจำนวนเต็มที่เรียงลำดับกันซึ่งเชื่อมโยงกับไฟล์ที่เปิดอยู่โดยเฉพาะ

หากโปรแกรมใช้ API การจัดการไฟล์แบบใหม่เพื่อเปิดไฟล์ ระบบปฏิบัติการจะจัดการโครงสร้างข้อมูลภายในที่เกี่ยวข้องกับไฟล์นั้นในพื้นที่หน่วยความจำของตัวเอง ซึ่งมีข้อดีอย่างมากคือ โครงสร้างเหล่านี้สามารถขยายขนาดได้ในระบบปฏิบัติการเวอร์ชันต่อๆ ไปโดยไม่ทำให้โปรแกรมแอปพลิเคชันเสียหาย ข้อเสียคือ เนื่องจากการจัดการหน่วยความจำ ที่ค่อนข้างเรียบง่าย ของ DOS พื้นที่สำหรับโครงสร้างเหล่านี้จำนวนมากเท่าที่โปรแกรมที่ "ใช้ไฟล์มากที่สุด" น่าจะใช้จะต้องถูกสงวนไว้ในระหว่างการบูต และไม่สามารถนำไปใช้เพื่อวัตถุประสงค์อื่นใดในขณะที่คอมพิวเตอร์กำลังทำงาน การสงวนหน่วยความจำดังกล่าวทำได้โดยใช้ คำสั่ง FILES = ใน ไฟล์ CONFIG.SYSปัญหานี้จะไม่เกิดขึ้นกับ FCB ใน DOS 1 หรือใน CP/M เนื่องจากระบบปฏิบัติการจะจัดเก็บทุกสิ่งที่จำเป็นต้องรู้เกี่ยวกับไฟล์ที่เปิดอยู่ภายใน FCB ดังนั้นจึงไม่จำเป็นต้องใช้หน่วยความจำต่อไฟล์ในพื้นที่หน่วยความจำของระบบปฏิบัติการ เมื่อใช้ FCB ใน MS-DOS 3 หรือเวอร์ชันที่ใหม่กว่า รูปแบบของ FCB จะขึ้นอยู่กับว่า SHARE.EXE ถูกโหลดหรือไม่ และ FCB นั้นอ้างอิงถึงไฟล์ในเครื่องหรือไฟล์ระยะไกล และมักจะอ้างอิงถึงรายการ SFT ด้วยเหตุนี้ จำนวน FCB ที่สามารถเปิดพร้อมกันได้ใน DOS 3 หรือเวอร์ชันที่สูงกว่าจึงมีจำกัดเช่นกัน โดยปกติจะอยู่ที่ 4 รายการ การใช้ คำสั่ง FCBS = ในไฟล์ CONFIG.SYS สามารถเพิ่มจำนวน FCB ให้มากกว่านั้นได้หากจำเป็น ภายใต้DR-DOSทั้ง FILES และ FCBS มาจากพูลโครงสร้างแฮนเดิลภายในเดียวกัน และจะถูกกำหนดแบบไดนามิกตามความจำเป็น^{[ 5 ]}

FCB ได้รับการสนับสนุนใน MS-DOS และWindows ทุกเวอร์ชัน จนกระทั่งมีการนำระบบไฟล์FAT32 มาใช้ Windows 95 , Windows 98และWindows Meไม่รองรับการใช้ FCB บนไดรฟ์ FAT32 เนื่องจากหมายเลขคลัสเตอร์ 32 บิต^{[ 4 ]}ยกเว้นการอ่านป้ายชื่อไดรฟ์ ซึ่งทำให้แอปพลิเคชัน DOS เก่าบางตัว รวมถึงWordStarล้มเหลวใน Windows เวอร์ชันเหล่านี้

อินเทอร์เฟซ FCB ใช้งานไม่ได้อย่างถูกต้องบนWindows NT , 2000ฯลฯ – WordStar ไม่ทำงานอย่างถูกต้องบนระบบปฏิบัติการเหล่านี้ โปรแกรมจำลอง DOS อย่าง DOSEMUและDOSBoxสามารถใช้งานอินเทอร์เฟซ FCB ได้อย่างถูกต้อง ดังนั้นจึงเป็นวิธีหนึ่งในการเรียกใช้โปรแกรม DOS เก่าๆ ที่ต้องการ FCB บนระบบปฏิบัติการสมัยใหม่

โครงสร้างข้อมูลเสริมที่ใช้ร่วมกับ FCB คือDisk Transfer Area (DTA) ^{[ 2 ]}นี่คือชื่อที่ใช้เรียกบัฟเฟอร์ซึ่งจะอ่าน/เขียนเนื้อหาไฟล์ (เรคอร์ด) เข้าไป ฟังก์ชันการเข้าถึงไฟล์ใน DOS ที่ใช้ FCB จะถือว่า DTA อยู่ในตำแหน่งคงที่ โดยในตอนแรกจะชี้ไปยังส่วนหนึ่งของ PSP (ดูส่วนถัดไป) ตำแหน่งนี้สามารถเปลี่ยนแปลงได้โดยการเรียกใช้ฟังก์ชัน DOS และการเข้าถึงไฟล์ในครั้งต่อๆ ไปจะใช้ตำแหน่งใหม่โดยปริยาย

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

ทุกโปรแกรมปฏิบัติการ DOS ที่เริ่มต้นจากเชลล์ ( COMMAND.COM ) จะได้รับโครงสร้างข้อมูลที่เติมไว้ล่วงหน้าความยาว 256 ไบต์ที่เรียกว่าProgram Segment Prefix (PSP) ฟิลด์ที่เกี่ยวข้องภายในโครงสร้างนี้ได้แก่: ^{[ 2 ]}

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

ที่อยู่เริ่มต้นของ DTA ถูกตั้งค่าให้ทับซ้อนกับพื้นที่ใน PSP (ที่อยู่ 0x80) ซึ่งเป็นที่เก็บอาร์กิวเมนต์บรรทัดคำสั่ง ดังนั้นโปรแกรมจึงจำเป็นต้องวิเคราะห์พื้นที่นี้เพื่อหาอาร์กิวเมนต์บรรทัดคำสั่งก่อนที่จะเรียกใช้ฟังก์ชัน DOS ที่ใช้ DTA (เช่น การอ่านระเบียนไฟล์) เว้นแต่ว่าโปรแกรมจะระมัดระวังในการเปลี่ยนที่อยู่ของ DTA ไปยังพื้นที่หน่วยความจำอื่น (หรือไม่ใช้ฟังก์ชัน DTA/FCB เลย ซึ่งต่อมาถูกยกเลิกและแทนที่ด้วยการใช้ตัวจัดการไฟล์)

• ระบบไฟล์แบบบันทึกข้อมูล

• Brown, Ralf D. , บรรณาธิการ (17 กรกฎาคม 2543). "210F: DOS 1+ - เปิดไฟล์โดยใช้ FCB" . รายการขัดจังหวะของ Ralf Brown 61 . ctyme.com. เก็บถาวรจากต้นฉบับเมื่อ 19 มิถุนายน 2559[7]
• Elliott, John C. (2002-12-29). "CP/M File Control Block" . Seasip.info . เก็บถาวรจากต้นฉบับเมื่อ 2017-08-23 . เรียกดูเมื่อ2017-08-23 .
• "CP/M Internals" . 2017-08-23. เก็บถาวรจากต้นฉบับเมื่อ 2017-08-23 . เรียกดูเมื่อ2017-08-23 .- คำอธิบายโดยละเอียดเกี่ยวกับ CP/M FCB