To install click the Add extension button. That's it.

The source code for the WIKI 2 extension is being checked by specialists of the Mozilla Foundation, Google, and Apple. You could also do it yourself at any point in time.

4,5
Kelly Slayton
Congratulations on this excellent venture… what a great idea!
Alexander Grigorievskiy
I use WIKI 2 every day and almost forgot how the original Wikipedia looks like.
Live Statistics
English Articles
Improved in 24 Hours
Added in 24 Hours
Languages
Recent
Show all languages
What we do. Every page goes through several hundred of perfecting techniques; in live mode. Quite the same Wikipedia. Just better.
.
Leo
Newton
Brights
Milds

Compound File Binary Format

From Wikipedia, the free encyclopedia

Compound File Binary Format (CFBF), also called Compound File, Compound Document format,[1] or Composite Document File V2[2] (CDF), is a compound document file format for storing numerous files and streams within a single file on a disk. CFBF is developed by Microsoft and is an implementation of Microsoft COM Structured Storage.[3][4][5]

Microsoft has opened the format for use by others and it is now used in a variety of programs from Microsoft Word and Microsoft Access to Business Objects.[citation needed] It also forms the basis of the Advanced Authoring Format.[6]

YouTube Encyclopedic

  • 1/3
    Views:
    1 413 738
    620
    4 767
  • Writing Ionic Formulas: Introduction
  • CS Principles: Unit 1 Day 5: Bitmaps encoding and decoding
  • CppCon 2017: Andrew Sutton “Reflection”

Transcription

Overview

At its simplest, the Compound File Binary Format is a container, with little restriction on what can be stored within it.

A CFBF file structure loosely resembles a FAT filesystem. The file is partitioned into Sectors which are chained together with a File Allocation Table (not to be mistaken with the file system of the same name) which contains chains of sectors related to each file, a Directory holds information for contained files with a Sector ID (SID) for the starting sector of a chain and so on.

Structure

The CFBF file consists of a 512-Byte header record followed by a number of sectors whose size is defined in the header. The literature defines Sectors to be either 512 or 4096 bytes in length, although the format is potentially capable of supporting sectors ranging in size from 128-Bytes upwards in powers of 2 (128, 256, 512, 1024, etc.). The lower limit of 128 is the minimum required to fit a single directory entry in a Directory Sector.[relevant?]

There are several types of sector that may be present in a CFBF:

  • File Allocation Table (FAT) Sector – contains chains of sector indices much as a FAT does in the FAT/FAT32 filesystems
  • MiniFAT Sectors – similar to the FAT but storing chains of mini-sectors within the Mini-Stream
  • Double-Indirect FAT (DIFAT) Sector – contains chains of FAT sector indices
  • Directory Sector – contains directory entries
  • Stream Sector – contains arbitrary file data
  • Range Lock Sector – contains the byte-range locking area of a large file

More detail is given below for the header and each sector type.

CFBF Header format

The CFBF Header occupies the first 512 bytes of the file and information required to interpret the rest of the file. The C-Style structure declaration below (extracted from the AAFA's Low-Level Container Specification) shows the members of the CFBF header and their purpose:

 typedef unsigned long ULONG;    // 4 Bytes
 typedef unsigned short USHORT;  // 2 Bytes
 typedef short OFFSET;           // 2 Bytes
 typedef ULONG SECT;             // 4 Bytes
 typedef ULONG FSINDEX;          // 4 Bytes
 typedef USHORT FSOFFSET;        // 2 Bytes
 typedef USHORT WCHAR;           // 2 Bytes
 typedef ULONG DFSIGNATURE;      // 4 Bytes
 typedef unsigned char BYTE;     // 1 Byte
 typedef unsigned short WORD;    // 2 Bytes
 typedef unsigned long DWORD;    // 4 Bytes
 typedef ULONG SID;              // 4 Bytes
 typedef GUID CLSID;             // 16 Bytes

 struct StructuredStorageHeader { // [offset from start (bytes), length (bytes)]
     BYTE _abSig[8];             // [00H,08] {0xd0, 0xcf, 0x11, 0xe0, 0xa1, 0xb1,
                                 // 0x1a, 0xe1} for current version
     CLSID _clsid;               // [08H,16] reserved must be zero (WriteClassStg/
                                 // GetClassFile uses root directory class id)
     USHORT _uMinorVersion;      // [18H,02] minor version of the format: 33 is
                                 // written by reference implementation
     USHORT _uDllVersion;        // [1AH,02] major version of the dll/format: 3 for
                                 // 512-byte sectors, 4 for 4 KB sectors
     USHORT _uByteOrder;         // [1CH,02] 0xFFFE: indicates Intel byte-ordering
     USHORT _uSectorShift;       // [1EH,02] size of sectors in power-of-two;
                                 // typically 9 indicating 512-byte sectors
     USHORT _uMiniSectorShift;   // [20H,02] size of mini-sectors in power-of-two;
                                 // typically 6 indicating 64-byte mini-sectors
     USHORT _usReserved;         // [22H,02] reserved, must be zero
     ULONG _ulReserved1;         // [24H,04] reserved, must be zero
     FSINDEX _csectDir;          // [28H,04] must be zero for 512-byte sectors,
                                 // number of SECTs in directory chain for 4 KB
                                 // sectors
     FSINDEX _csectFat;          // [2CH,04] number of SECTs in the FAT chain
     SECT _sectDirStart;         // [30H,04] first SECT in the directory chain
     DFSIGNATURE _signature;     // [34H,04] signature used for transactions; must
                                 // be zero. The reference implementation
                                 // does not support transactions
     ULONG _ulMiniSectorCutoff;  // [38H,04] maximum size for a mini stream;
                                 // typically 4096 bytes
     SECT _sectMiniFatStart;     // [3CH,04] first SECT in the MiniFAT chain
     FSINDEX _csectMiniFat;      // [40H,04] number of SECTs in the MiniFAT chain
     SECT _sectDifStart;         // [44H,04] first SECT in the DIFAT chain
     FSINDEX _csectDif;          // [48H,04] number of SECTs in the DIFAT chain
     SECT _sectFat[109];         // [4CH,436] the SECTs of first 109 FAT sectors
 };

File Allocation Table (FAT) Sectors

When taken together as a single stream the collection of FAT sectors define the status and linkage of every sector in the file. Each entry in the FAT is 4 bytes in length and contains the sector number of the next sector in a FAT chain or one of the following special values:

  • FREESECT (0xFFFFFFFF) – denotes an unused sector
  • ENDOFCHAIN (0xFFFFFFFE) – marks the last sector in a FAT chain
  • FATSECT (0xFFFFFFFD) – marks a sector used to store part of the FAT
  • DIFSECT (0xFFFFFFFC) – marks a sector used to store part of the DIFAT

Range Lock Sector

The Range Lock Sector must exist in files greater than 2GB in size, and must not exist in files smaller than 2GB. The Range Lock Sector must contain the byte range 0x7FFFFF00 to 0x7FFFFFFF in the file. This area is reserved by Microsoft's COM implementation for storing byte-range locking information for concurrent access.

Glossary

  • FAT – File Allocation Table, also known as: SAT – Sector Allocation Table
  • DIFAT – Double-Indirect File Allocation Table
  • FAT Chain – a group of FAT entries which indicate the sectors allocated to a Stream in the file
  • Stream – a virtual file which occupies a number of sectors within the CFBF
  • Sector – the unit of allocation within the CFBF, usually 512 or 4096 Bytes in length

See also

References

  1. ^ "Apache POI – POIFS". POI Project. Archived from the original on 26 April 2011. Retrieved 10 May 2011.
  2. ^ "How to convert documents between LibreOffice and Microsoft Office file formats on Linux". Archived from the original on 21 September 2019. Retrieved 25 November 2016.
  3. ^ "Compound Files (Windows)". Microsoft Developers Network (MSDN) library – COM SDK. Microsoft Corporation. 20 November 2008. Retrieved 23 September 2009.
  4. ^ "Containers: Compound Files". Microsoft Developers Network (MSDN) library – Visual Studio 2008 documentation. Microsoft Corporation. Retrieved 23 September 2009.
  5. ^ "Understand Compound Files". Microsoft Developers Network (MSDN) library – ActiveDirectory Rights Management. 25 June 2009. Retrieved 23 September 2009.
  6. ^ AMW Association (formerly AAF Association) Archived 15 August 2000 at the Wayback Machine

External links

This page was last edited on 5 January 2024, at 17:46
Basis of this page is in Wikipedia. Text is available under the CC BY-SA 3.0 Unported License. Non-text media are available under their specified licenses. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc. WIKI 2 is an independent company and has no affiliation with Wikimedia Foundation.