Use bold in table headings
This commit is contained in:
parent
616b16f7db
commit
2db3303f90
16
Format.md
16
Format.md
@ -33,7 +33,7 @@ major and minor numbers for every file even though those numbers mean nothing
|
|||||||
except for when the file in question is a Unix block or character device.
|
except for when the file in question is a Unix block or character device.
|
||||||
|
|
||||||
Another thing that Tar does is it creates a *lot* of padding when you have
|
Another thing that Tar does is it creates a *lot* of padding when you have
|
||||||
a lot of small files. You not only have padding inside the header metadata,
|
a bunch of small files. You not only have padding inside the header metadata,
|
||||||
which includes storing the above mentioned useless data, but also padding in
|
which includes storing the above mentioned useless data, but also padding in
|
||||||
between data blocks, as tar slices everything up into 512 byte blocks and
|
between data blocks, as tar slices everything up into 512 byte blocks and
|
||||||
pads the final block to reach that 512 byte number. This is of lesser impact
|
pads the final block to reach that 512 byte number. This is of lesser impact
|
||||||
@ -68,7 +68,7 @@ by 8, the third byte by 16 and the fourth byte by 24, and the bits combined
|
|||||||
into a single 32-bit uint. This is dramatically more efficient than storing
|
into a single 32-bit uint. This is dramatically more efficient than storing
|
||||||
those numbers as ascii text, as is done by Tar.
|
those numbers as ascii text, as is done by Tar.
|
||||||
|
|
||||||
| bytes | meaning |
|
| **bytes** | **meaning** |
|
||||||
| ----- | ------- |
|
| ----- | ------- |
|
||||||
| 0-8 | The length of the filename (64 bit unsigned int) |
|
| 0-8 | The length of the filename (64 bit unsigned int) |
|
||||||
| 8 to the length specified above | The bytes making up the filename |
|
| 8 to the length specified above | The bytes making up the filename |
|
||||||
@ -80,7 +80,7 @@ those numbers as ascii text, as is done by Tar.
|
|||||||
|
|
||||||
## File types
|
## File types
|
||||||
The file types represented by the final flag in the previous table are as follows:
|
The file types represented by the final flag in the previous table are as follows:
|
||||||
| flag | file type |
|
| **flag** | **file type** |
|
||||||
| ---- | --------- |
|
| ---- | --------- |
|
||||||
| 0 | Normal file |
|
| 0 | Normal file |
|
||||||
| 1 | Hard link |
|
| 1 | Hard link |
|
||||||
@ -94,7 +94,7 @@ The file types represented by the final flag in the previous table are as follow
|
|||||||
From here, the following data is interpreted according to the flag.
|
From here, the following data is interpreted according to the flag.
|
||||||
|
|
||||||
### Normal files
|
### Normal files
|
||||||
| bytes | meaning |
|
| **bytes** | **meaning** |
|
||||||
| ----- | ------- |
|
| ----- | ------- |
|
||||||
| next 8 bytes | The length of the file (64 bit unsigned int) |
|
| next 8 bytes | The length of the file (64 bit unsigned int) |
|
||||||
| next byte | a checksum type |
|
| next byte | a checksum type |
|
||||||
@ -102,7 +102,7 @@ From here, the following data is interpreted according to the flag.
|
|||||||
#### Checksum types
|
#### Checksum types
|
||||||
Haggis can optionally use md5, sha1 or sha256 checksumming inline during archive
|
Haggis can optionally use md5, sha1 or sha256 checksumming inline during archive
|
||||||
creation to ensure data integrity. The checksum flag is interpreted as follows:
|
creation to ensure data integrity. The checksum flag is interpreted as follows:
|
||||||
| flag | type |
|
| **flag** | **type** |
|
||||||
| ---- | ---- |
|
| ---- | ---- |
|
||||||
| 0 | md5 |
|
| 0 | md5 |
|
||||||
| 1 | sha1 |
|
| 1 | sha1 |
|
||||||
@ -112,7 +112,7 @@ creation to ensure data integrity. The checksum flag is interpreted as follows:
|
|||||||
#### The following bytes
|
#### The following bytes
|
||||||
If the checksum is not skipped, the the number of bytes making up the checksum
|
If the checksum is not skipped, the the number of bytes making up the checksum
|
||||||
depends on the algorithm being used.
|
depends on the algorithm being used.
|
||||||
| algorithm | bytes |
|
| **algorithm** | **bytes** |
|
||||||
| --------- | ----- |
|
| --------- | ----- |
|
||||||
| md5 | 16 |
|
| md5 | 16 |
|
||||||
| sha1 | 20 |
|
| sha1 | 20 |
|
||||||
@ -123,7 +123,7 @@ checksum, according to the length previously given. The next node follows immedi
|
|||||||
after the last byte of the file.
|
after the last byte of the file.
|
||||||
|
|
||||||
### Hard and soft links
|
### Hard and soft links
|
||||||
| bytes | meaning |
|
| **bytes** | **meaning** |
|
||||||
| ----- | ------- |
|
| ----- | ------- |
|
||||||
| next 8 | the **length** of the link target's file name |
|
| next 8 | the **length** of the link target's file name |
|
||||||
| the next **length** bytes | the link target's file name |
|
| the next **length** bytes | the link target's file name |
|
||||||
@ -134,7 +134,7 @@ The next byte will be the beginning of the following archive node.
|
|||||||
The next node follows immediately after the file type flag.
|
The next node follows immediately after the file type flag.
|
||||||
|
|
||||||
### Character or Block device file
|
### Character or Block device file
|
||||||
| bytes | meaning |
|
| **bytes** | **meaning** |
|
||||||
| ----- | ------- |
|
| ----- | ------- |
|
||||||
| next 4 | the device Major number |
|
| next 4 | the device Major number |
|
||||||
| next 4 | the device Minor number |
|
| next 4 | the device Minor number |
|
||||||
|
Loading…
Reference in New Issue
Block a user