jeang3nie/haggis-rs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Use bold in table headings

Browse Source
This commit is contained in:
Nathan Fisher 2023-07-05 00:35:48 -04:00
parent 616b16f7db
commit 2db3303f90
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
Format.md
View File

@ -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.
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
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
@ -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
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) |
| 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
The file types represented by the final flag in the previous table are as follows:
| flag | file type |
| **flag** | **file type** |
| ---- | --------- |
| 0 | Normal file |
| 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.
### Normal files
| bytes | meaning |
| **bytes** | **meaning** |
| ----- | ------- |
| next 8 bytes | The length of the file (64 bit unsigned int) |
| next byte | a checksum type |
@ -102,7 +102,7 @@ From here, the following data is interpreted according to the flag.
#### Checksum types
Haggis can optionally use md5, sha1 or sha256 checksumming inline during archive
creation to ensure data integrity. The checksum flag is interpreted as follows:
| flag | type |
| **flag** | **type** |
| ---- | ---- |
| 0 | md5 |
| 1 | sha1 |
@ -112,7 +112,7 @@ creation to ensure data integrity. The checksum flag is interpreted as follows:
#### The following bytes
If the checksum is not skipped, the the number of bytes making up the checksum
depends on the algorithm being used.
| algorithm | bytes |
| **algorithm** | **bytes** |
| --------- | ----- |
| md5 | 16 |
| 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.
### Hard and soft links
| bytes | meaning |
| **bytes** | **meaning** |
| ----- | ------- |
| next 8 | the **length** of 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.
### Character or Block device file
| bytes | meaning |
| **bytes** | **meaning** |
| ----- | ------- |
| next 4 | the device Major number |
| next 4 | the device Minor number |