Compact File Set (CFS)เป็นรูปแบบไฟล์เก็บถาวร แบบเปิด และเป็นรูปแบบไฟล์คอนเทนเนอร์สำหรับการแจกจ่ายซอฟต์แวร์

ชุดไฟล์ขนาดกะทัดรัด (CFS)เป็นรูปแบบไฟล์เก็บถาวร แบบเปิด และรูปแบบไฟล์คอนเทนเนอร์สำหรับการแจกจ่ายซอฟต์แวร์^{[ 1 ]}ไฟล์ CFS พื้นฐานเข้ากันได้กับไฟล์ ISO โดยมีจุดประสงค์เพื่อให้มีความคล้ายคลึงกับ ISO-9660 มากพอที่ระบบและแอปพลิเคชันจำนวนมากจะสามารถอ่าน CFS ได้ และแอปพลิเคชันอื่นๆ จะต้องการการแก้ไขเพียงเล็กน้อยเท่านั้น โดยมีพื้นฐานมาจาก:

• ไอโอเอส9660
• โจลิเอต (ระบบไฟล์)
• ISO-9660:1999
• ไอโซคอมแพ็ก

สามารถใช้งานได้ในแอปพลิเคชันฟรีหรือเชิงพาณิชย์โดยไม่เสียค่าใช้จ่าย คาดว่าไม่มีส่วนใดของรูปแบบนี้อยู่ภายใต้สิทธิบัตร^{[ 2 ]}

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

• ลดความซับซ้อนในการใช้งานด้วยการบีบอัดข้อมูลและการจัดเก็บข้อมูลแบบไม่กำหนดตำแหน่ง (ท่อส่งข้อมูล, ซ็อกเก็ต, เทป)
• ช่วยลดความซับซ้อนในการใช้งานแอปพลิเคชันการอ่านและการเขียน เมื่อเทียบกับอิมเมจแบบ ISO-9660/UDF แบบดั้งเดิม
• ปรับปรุงความสม่ำเสมอและการแลกเปลี่ยนข้อมูลระหว่างแอปพลิเคชันต่างๆ ให้ดียิ่งขึ้น
• ลดความซับซ้อนในการใช้งานแอปพลิเคชันที่แก้ไขรูปภาพ
• เพิ่มประสิทธิภาพการจัดเก็บข้อมูลโดยใช้พื้นที่รูปภาพน้อยลงสำหรับโครงสร้างสื่อและข้อมูลไดเร็กทอรีที่ซ้ำกัน
• ยกเลิกข้อจำกัดจำนวนโฟลเดอร์ที่กำหนดโดยตารางพาธในมาตรฐาน ISO-9660
• ขจัดข้อจำกัดด้านขนาดไฟล์ที่เกิดจากข้อจำกัดด้านความเข้ากันได้ต่างๆ ในการใช้งาน ISO-9660 และ UDF

• รูปแบบและเนื้อหาของส่วนหัวสื่อ (40 KB แรก) นั้นคงที่ โดยจะมีลำดับโครงสร้างของวอลุ่มและข้อมูลเหมือนเดิมเสมอ
• ชื่อไฟล์และช่องข้อความทั้งหมดจะถูกจัดเก็บในรูปแบบ UCS-2 แบบ big-endian ตามที่ระบุไว้ในส่วนขยายของ Joliet
• ข้อจำกัดโดยพลการเกี่ยวกับชื่อไฟล์และความลึกของไดเร็กทอรีถูกยกเลิก โดยจำกัดไว้ไม่เกินขอบเขตของโครงสร้างระเบียนไฟล์ ISO-9660 ซึ่งก็คืออักขระ 16 บิตจำนวน 110 ตัว
• ข้อมูลทั้งหมดในไดเร็กทอรีจะถูกเขียนต่อจากบล็อกข้อมูลไฟล์สุดท้าย
• ผู้อ่านจะต้องสามารถจัดการกับไฟล์ที่มีขนาดเกิน 4 GB ได้
• ตารางเส้นทางถูกสร้างขึ้นโดยไม่จำเป็น แต่ไม่ได้นำมาใช้งาน

20 บล็อกแรก (40 KB) ของอิมเมจเชิงตรรกะคือส่วนหัวของสื่อ โครงสร้างของส่วนหัวของสื่อนั้นเข้ากันได้กับโครงสร้างตัวอธิบายและไดเร็กทอรีต่างๆ สำหรับ ISO-9660 บล็อกแรกของข้อมูลไฟล์จะถูกจัดเก็บไว้ในบล็อกที่ 20 ถัดจากส่วนหัวของสื่อทันที

ส่วนหัวของสื่อมีรูปแบบดังต่อไปนี้:

บล็อก 0-11

ศูนย์ทั้งหมด

บล็อก 12

ข้อความในไฟล์ readme เกี่ยวกับความเข้ากันได้

บล็อก 13

โฟลเดอร์รากความเข้ากันได้

บล็อก 14

ตารางเส้นทางความเข้ากันได้แบบ little-endian

บล็อก 15

ตารางเส้นทางบิ๊กเอนเดียนที่เข้ากันได้

บล็อก 16

คำอธิบายปริมาตรหลักที่เข้ากันได้กับ ISO-9660

บล็อก 17

คำอธิบายปริมาตรเสริม ISO-9660

บล็อก 18

คำอธิบายการสิ้นสุด ISO-9660

บล็อก 19

ศูนย์ทั้งหมด

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

ชื่อไฟล์ทั้งหมด รวมถึงรหัสระบบและรหัสวอลุ่มในตัวอธิบายวอลุ่มเสริม จะถูกเข้ารหัสเป็น UCS-2 แบบ big-endian

ความยาวของชื่อไฟล์ถูกจำกัดโดยขนาดระเบียนไฟล์ 8 บิตไว้ที่ 110 อักขระ 16 บิต ไม่มีการกำหนดข้อจำกัดโดยพลการเกี่ยวกับความลึกของลำดับชั้นของไดเร็กทอรีหรือความยาวรวมของชื่อไฟล์และส่วนประกอบชื่อโฟลเดอร์ที่รวมอยู่ ผู้อ่านจะต้องเลือกข้อจำกัดที่เหมาะสมสำหรับสภาพแวดล้อมของตนและทำการตรวจสอบตามความจำเป็น เช่นเดียวกับใน ISO-9660-1999 หมายเลขเวอร์ชันจะไม่ถูกเพิ่มลงในชื่อไฟล์ และเช่นเดียวกับใน ISO-9660-1999 ความหมายพิเศษของ อักขระ < .และ < ;ในระหว่างการเรียงลำดับชื่อไฟล์จะถูกตัดออกไป

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

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

Duplicate file records are to be used only to allow representing files with data extents that are larger than 4GiB-2048. Duplicate file records are not to be used to represent files with fragmented data. When duplicate file records are used, the multi-extent flag must also be used as indicated in ISO-9660-1999 specification. Duplicate file records should not be created unless the total data size of the file is greater than 4Gib-2048. When duplicate file records exist for a file, all but the last file record must have a data extent that is exactly 4Gib-2048 bytes in size.

All file data must precede all folder extents and path tables on media. The intent is that an image modifying application can read the entire directory into memory, add new file data to the image, and rewrite an updated directory after the new file data. Writers will need to determine the last block of file data after reading the entire directory.

When the media header is modified, either at the end of image creation or as part of later modifications to an existing image, only some specific fields are to be updated. These fields exist entirely within the media header patch area. Only the media header patch area should be re-written. This allows more options when dealing with image container file formats or transports with limited seeking or overwrite capability (compressed formats, pipes, sockets).

All files and folders written in the image must be accessible through the single directory structure referenced from the supplementary volume descriptor. Compound file systems, such as including UDF or HFS structures, are not allowed. Rockridge and other ISO-9660 extensions are not allowed.

Future versions of CFS may include extensions to allow storing system specific attributes such as time fields, security descriptors, access control lists, resource forks, symbolic links etc.. Developers with a need for these extensions should contact Pismo Technic with requirements and/or suggestions.

CFS images are either written to CD/DVD media, or are stored in a media container file. The media container file can be a raw dump of the CFS image, referred to here as DD, but more commonly known as ISO files. Also, the media container file can be a more structured container format that provides additional features such as compression and spanning. CFS images are only compliant with this specification when they are stored in DD or CISO (Compact ISO) format media files. When burned to CD/DVD media or when stored in other media container file formats such as NRG or DAA, the combination is not CFS compliant and should not be referred to as a CFS file.

หมายเหตุ: ไฟล์ ISO แบบบีบอัด (Compact ISO)ไม่ใช่รูปแบบเดียวกับไฟล์ ISO แบบบีบอัด (Compressed ISO) ที่ใช้กันทั่วไปในการพัฒนาโฮมบรูว์สำหรับ PlayStation Portableไฟล์ ISO แบบบีบอัดของ PSP เรียกอีกอย่างว่า CISO แต่ส่วนขยายไฟล์จะเป็น CSO

โปรแกรมที่ใช้เขียนไฟล์ CFS ควรตั้งค่าเริ่มต้นเป็นการเขียนไฟล์คอนเทนเนอร์สื่อในรูปแบบ DD เว้นแต่ผู้ใช้จะระบุตัวเลือกไฟล์คอนเทนเนอร์ที่ต้องการ CISO (เช่น การแบ่งส่วน การบีบอัด ฯลฯ) วิธีนี้จะช่วยให้การแลกเปลี่ยนข้อมูลกับระบบและแอปพลิเคชันที่รองรับอิมเมจ CD/DVD ในรูปแบบ DD แต่ไม่รองรับ CFS เป็นไปอย่างเป็นธรรมชาติมากขึ้น

• การเปรียบเทียบรูปแบบไฟล์เก็บถาวร
• รายการรูปแบบไฟล์เก็บถาวร
• รูปแบบไฟล์ฟรี
• รูปแบบเปิด

• CFS (Compact File Set)จากPismo Technic