Slack Space
Slack Space is area of storage or disk that is empty but still contain data. When a file is deleted just pointer to it is removed, if look at the disk byte for byte you still can look deleted data.
That mean slack space is zone of data has deleted by user or system can to recovery later, if data still available in Slack Space enable to recovered or in other mean slack space is place of temporary data when data removed in storage system by user or system.
Slack space is unused cluster space, several file syatem use unit cluster as smallest unit file.
Unallocated Space
Unallocated Space is Clusters of a media partition not in use for storing any active files. They may contain pieces of files that were deleted from the file partition but not removed from the physical disk, I guess that is zero space in disk storage contain data partition system.
Look like picture above, unallocated space is unpartition part in disk storage, that place is unused by file system and cant to write anything data inside to place by operating system. space on a hard drive that potentially contains intact files, remnants of files, subdirectories or temporary files which were created and then deleted by either a computer application, the operating system or the operator.
Magic Number
A constant numerical or text value used to identify a file format or protocol, Magic numbers are common in programs across many operating systems. Magic numbers implement strongly typed data and are a form of in-band signaling to the controlling program that reads the data type(s) at program run-time. Many files have such constants that identify the contained data. Detecting such constants in files is a simple and effective way of distinguishing between many file formats and can yield further run-time information.
Example of Structure File
Txt File Format and File Structure
The text file structure consists of a stream of 8-bit ASCII characters. Every record in a text file is terminated by a newline character (\n, ASCII 012). Some utilities may omit the newline character on the last record, but the Fortran library will treat such an occurrence as a malformed record. This file structure can be specified for a file that is declared as formatted sequential access or formatted direct access. It is the default file structure for formatted sequential access files. On UNICOS and UNICOS/mk systems, it is also the default file structure for formatted direct access files.
AVI File Structure
The AVI file format is based on the RIFF (resource interchange file format) document format. A RIFF file consists of a RIFF header followed by zero or more lists and chunks.
- The RIFF header has the following form:
'RIFF' fileSize fileType (data)
where 'RIFF' is the literal FOURCC code 'RIFF', fileSize
is a 4-byte value giving the size of the data in the file, and fileType
is a FOURCC that identifies the specific file type. The value of fileSize
includes the size of the fileType
FOURCC plus the size of the data that follows, but does not include the size of the 'RIFF' FOURCC or the size of fileSize
. The file data consists of chunks and lists, in any order.
- A chunk has the following form:
ckID ckSize ckData
where ckID
is a FOURCC that identifies the data contained in the chunk, ckSize
is a 4-byte value giving the size of the data in ckData
, and ckData
is zero or more bytes of data. The data is always padded to nearest WORD boundary. ckSize
gives the size of the valid data in the chunk; it does not include the padding, the size of ckID
, or the size of ckSize
.
- A list has the following form:
'LIST' listSize listType listData
where 'LIST' is the literal FOURCC code 'LIST', listSize
is a 4-byte value giving the size of the list, listType
is a FOURCC code, and listData
consists of chunks or lists, in any order. The value of listSize
includes the size of listType
plus the size of listData
; it does not include the 'LIST' FOURCC or the size of listSize
.
The remainder of this section uses the following notation to describe RIFF chunks:
ckID ( ckData )
where the chunk size is implicit. Using this notation, a list can be represented as:
'LIST' ( listType ( listData ) )
Optional elements are placed in brackets: [ optional element ]
AVI Form
AVI files are identified by the FOURCC 'AVI ' in the RIFF header. All AVI files include two mandatory LIST chunks, which define the format of the streams and the stream data, respectively. An AVI file might also include an index chunk, which gives the location of the data chunks within the file. An AVI file with these components has the following form:
The 'hdrl' list defines the format of the data and is the first required LIST chunk. The 'movi' list contains the data for the AVI sequence and is the second required LIST chunk. The 'idx1' list contains the index. AVI files must keep these three components in the proper sequence.
Note The OpenDML extensions define another type of index, identified by the FOURCC 'indx'.
The 'hdrl' and 'movi' lists use subchunks for their data. The following example shows the AVI RIFF form expanded with the chunks needed to complete these lists:
Main Header
The 'hdrl' list begins with the main AVI header, which is contained in an 'avih' chunk. The main header contains global information for the entire AVI file, such as the number of streams within the file and the width and height of the AVI sequence. The main header chunk consists of an
AVI Main Header structure.
Stream Header
One or more 'strl' lists follow the main header. A 'strl' list is required for each data stream. Each 'strl' list contains information about one stream in the file, and must contain a stream header chunk ('strh') and a stream format chunk ('strf'). In addition, a 'strl' list might contain a stream-header data chunk ('strd') and a stream name chunk ('strn').
The stream header chunk ('strh') consists of an AVISTREAMHEADER structure.
A stream format chunk ('strf') must follow the stream header chunk. The stream format chunk describes the format of the data in the stream. The data contained in this chunk depends on the stream type. For video streams, the information is a BITMAPINFO structure, including palette information if appropriate. For audio streams, the information is a WAVEFORMATEX
structure.
If the stream-header data ('strd') chunk is present, it follows the stream format chunk. The format and content of this chunk are defined by the codec driver. Typically, drivers use this information for configuration. Applications that read and write AVI files do not need to interpret this information; they simple transfer it to and from the driver as a memory block.
The optional 'strn' chunk contains a null-terminated text string describing the stream.
The stream headers in the 'hdrl' list are associated with the stream data in the 'movi' list according to the order of the 'strl' chunks. The first 'strl' chunk applies to stream 0, the second applies to stream 1, and so forth.
Stream Data
Following the header information is a 'movi' list that contains the actual data in the streams—that is, the video frames and audio samples. The data chunks can reside directly in the 'movi' list, or they might be grouped within 'rec ' lists. The 'rec ' grouping implies that the grouped chunks should be read from disk all at once, and is intended for files that are interleaved to play from CD-ROM.
The FOURCC that identifies each data chunk consists of a two-digit stream number followed by a two-character code that defines the type of information in the chunk.
Index Entries
- AVI 1.0 index
- An optional index ('idx1') chunk can follow the 'movi' list. The index contains a list of the data chunks and their location in the file. It consists of an AVIOLDINDEX structure with entries for each data chunk, including 'rec ' chunks. If the file contains an index, set the AVIF_HASINDEX flag in the dwFlags member of the AVIMAINHEADER structure.
- AVI 2.0 index
- An AVI 2.0 index can appear as a single chunk. Alternatively, index segments can be interleaved within the 'movi' chunk. If the index segments are placed in the 'movi' chunk, a super index contains an index of the index segments. The AVIMETAINDEX structure is the base structure for both the index segments and the super index. For more information, see the OpenDML AVI File Format Extensions, published by the OpenDML AVI M-JPEG File Format Subcommittee. (This resource may not be available in some languages and countries.