записывать контрольные суммы и размеры файлов (write file checksums and sizes)
Пролог (Prolog)
This manual page is part of the POSIX Programmer's Manual. The
Linux implementation of this interface may differ (consult the
corresponding Linux manual page for details of Linux behavior),
or the interface may not be implemented on Linux.
Имя (Name)
cksum — write file checksums and sizes
Синопсис (Synopsis)
cksum [file...]
Описание (Description)
The cksum utility shall calculate and write to standard output a
cyclic redundancy check (CRC) for each input file, and also write
to standard output the number of octets in each file. The CRC
used is based on the polynomial used for CRC error checking in
the ISO/IEC 8802‐3:1996 standard (Ethernet).
The encoding for the CRC checksum is defined by the generating
polynomial:
G(x)=x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1
Mathematically, the CRC value corresponding to a given file shall
be defined by the following procedure:
1. The n bits to be evaluated are considered to be the
coefficients of a mod 2 polynomial M(x) of degree n-1. These
n bits are the bits from the file, with the most significant
bit being the most significant bit of the first octet of the
file and the last bit being the least significant bit of the
last octet, padded with zero bits (if necessary) to achieve
an integral number of octets, followed by one or more octets
representing the length of the file as a binary value, least
significant octet first. The smallest number of octets
capable of representing this integer shall be used.
2. M(x) is multiplied by x32 (that is, shifted left 32 bits) and
divided by G(x) using mod 2 division, producing a remainder
R(x) of degree ≤ 31.
3. The coefficients of R(x) are considered to be a 32-bit
sequence.
4. The bit sequence is complemented and the result is the CRC.
Параметры (Options)
None.
Операнды (Operands)
The following operand shall be supported:
file A pathname of a file to be checked. If no file operands
are specified, the standard input shall be used.
Стандартный ввод (Stdin)
The standard input shall be used if no file operands are
specified, and shall be used if a file operand is '-' and the
implementation treats the '-' as meaning standard input.
Otherwise, the standard input shall not be used. See the INPUT
FILES section.
Входные файлы (Input files)
The input files can be any file type.
Переменные окружения (Environment variables)
The following environment variables shall affect the execution of
cksum:
LANG Provide a default value for the internationalization
variables that are unset or null. (See the Base
Definitions volume of POSIX.1‐2017, Section 8.2,
Internationalization Variables for the precedence of
internationalization variables used to determine the
values of locale categories.)
LC_ALL If set to a non-empty string value, override the values
of all the other internationalization variables.
LC_CTYPE Determine the locale for the interpretation of
sequences of bytes of text data as characters (for
example, single-byte as opposed to multi-byte
characters in arguments).
LC_MESSAGES
Determine the locale that should be used to affect the
format and contents of diagnostic messages written to
standard error.
NLSPATH Determine the location of message catalogs for the
processing of LC_MESSAGES.
Асинхронные события (Asynchronous events)
Default.
Стандартный вывод (Stdout)
For each file processed successfully, the cksum utility shall
write in the following format:
"%u %d %s\n", <checksum>, <# of octets>, <pathname>
If no file operand was specified, the pathname and its leading
<space> shall be omitted.
Стандартный вывод сообщений (Stderr)
The standard error shall be used only for diagnostic messages.
Выходные файлы (Output files)
None.
Расширенное описание (Extended description)
None.
Статус выхода (Exit)
The following exit values shall be returned:
0 All files were processed successfully.
>0 An error occurred.
Последствия ошибок (Consequences of errors)
Default.
The following sections are informative.
Использование в приложениях (Application usage)
The cksum utility is typically used to quickly compare a suspect
file against a trusted version of the same, such as to ensure
that files transmitted over noisy media arrive intact. However,
this comparison cannot be considered cryptographically secure.
The chances of a damaged file producing the same CRC as the
original are small; deliberate deception is difficult, but
probably not impossible.
Although input files to cksum can be any type, the results need
not be what would be expected on character special device files
or on file types not described by the System Interfaces volume of
POSIX.1‐2017. Since this volume of POSIX.1‐2017 does not specify
the block size used when doing input, checksums of character
special files need not process all of the data in those files.
The algorithm is expressed in terms of a bitstream divided into
octets. If a file is transmitted between two systems and
undergoes any data transformation (such as changing little-endian
byte ordering to big-endian), identical CRC values cannot be
expected. Implementations performing such transformations may
extend cksum to handle such situations.
Примеры (Examples)
None.
Обоснование (Rationale)
The following C-language program can be used as a model to
describe the algorithm. It assumes that a char is one octet. It
also assumes that the entire file is available for one pass
through the function. This was done for simplicity in
demonstrating the algorithm, rather than as an implementation
model.
static unsigned long crctab[] = {
0x00000000,
0x04c11db7, 0x09823b6e, 0x0d4326d9, 0x130476dc, 0x17c56b6b,
0x1a864db2, 0x1e475005, 0x2608edb8, 0x22c9f00f, 0x2f8ad6d6,
0x2b4bcb61, 0x350c9b64, 0x31cd86d3, 0x3c8ea00a, 0x384fbdbd,
0x4c11db70, 0x48d0c6c7, 0x4593e01e, 0x4152fda9, 0x5f15adac,
0x5bd4b01b, 0x569796c2, 0x52568b75, 0x6a1936c8, 0x6ed82b7f,
0x639b0da6, 0x675a1011, 0x791d4014, 0x7ddc5da3, 0x709f7b7a,
0x745e66cd, 0x9823b6e0, 0x9ce2ab57, 0x91a18d8e, 0x95609039,
0x8b27c03c, 0x8fe6dd8b, 0x82a5fb52, 0x8664e6e5, 0xbe2b5b58,
0xbaea46ef, 0xb7a96036, 0xb3687d81, 0xad2f2d84, 0xa9ee3033,
0xa4ad16ea, 0xa06c0b5d, 0xd4326d90, 0xd0f37027, 0xddb056fe,
0xd9714b49, 0xc7361b4c, 0xc3f706fb, 0xceb42022, 0xca753d95,
0xf23a8028, 0xf6fb9d9f, 0xfbb8bb46, 0xff79a6f1, 0xe13ef6f4,
0xe5ffeb43, 0xe8bccd9a, 0xec7dd02d, 0x34867077, 0x30476dc0,
0x3d044b19, 0x39c556ae, 0x278206ab, 0x23431b1c, 0x2e003dc5,
0x2ac12072, 0x128e9dcf, 0x164f8078, 0x1b0ca6a1, 0x1fcdbb16,
0x018aeb13, 0x054bf6a4, 0x0808d07d, 0x0cc9cdca, 0x7897ab07,
0x7c56b6b0, 0x71159069, 0x75d48dde, 0x6b93dddb, 0x6f52c06c,
0x6211e6b5, 0x66d0fb02, 0x5e9f46bf, 0x5a5e5b08, 0x571d7dd1,
0x53dc6066, 0x4d9b3063, 0x495a2dd4, 0x44190b0d, 0x40d816ba,
0xaca5c697, 0xa864db20, 0xa527fdf9, 0xa1e6e04e, 0xbfa1b04b,
0xbb60adfc, 0xb6238b25, 0xb2e29692, 0x8aad2b2f, 0x8e6c3698,
0x832f1041, 0x87ee0df6, 0x99a95df3, 0x9d684044, 0x902b669d,
0x94ea7b2a, 0xe0b41de7, 0xe4750050, 0xe9362689, 0xedf73b3e,
0xf3b06b3b, 0xf771768c, 0xfa325055, 0xfef34de2, 0xc6bcf05f,
0xc27dede8, 0xcf3ecb31, 0xcbffd686, 0xd5b88683, 0xd1799b34,
0xdc3abded, 0xd8fba05a, 0x690ce0ee, 0x6dcdfd59, 0x608edb80,
0x644fc637, 0x7a089632, 0x7ec98b85, 0x738aad5c, 0x774bb0eb,
0x4f040d56, 0x4bc510e1, 0x46863638, 0x42472b8f, 0x5c007b8a,
0x58c1663d, 0x558240e4, 0x51435d53, 0x251d3b9e, 0x21dc2629,
0x2c9f00f0, 0x285e1d47, 0x36194d42, 0x32d850f5, 0x3f9b762c,
0x3b5a6b9b, 0x0315d626, 0x07d4cb91, 0x0a97ed48, 0x0e56f0ff,
0x1011a0fa, 0x14d0bd4d, 0x19939b94, 0x1d528623, 0xf12f560e,
0xf5ee4bb9, 0xf8ad6d60, 0xfc6c70d7, 0xe22b20d2, 0xe6ea3d65,
0xeba91bbc, 0xef68060b, 0xd727bbb6, 0xd3e6a601, 0xdea580d8,
0xda649d6f, 0xc423cd6a, 0xc0e2d0dd, 0xcda1f604, 0xc960ebb3,
0xbd3e8d7e, 0xb9ff90c9, 0xb4bcb610, 0xb07daba7, 0xae3afba2,
0xaafbe615, 0xa7b8c0cc, 0xa379dd7b, 0x9b3660c6, 0x9ff77d71,
0x92b45ba8, 0x9675461f, 0x8832161a, 0x8cf30bad, 0x81b02d74,
0x857130c3, 0x5d8a9099, 0x594b8d2e, 0x5408abf7, 0x50c9b640,
0x4e8ee645, 0x4a4ffbf2, 0x470cdd2b, 0x43cdc09c, 0x7b827d21,
0x7f436096, 0x7200464f, 0x76c15bf8, 0x68860bfd, 0x6c47164a,
0x61043093, 0x65c52d24, 0x119b4be9, 0x155a565e, 0x18197087,
0x1cd86d30, 0x029f3d35, 0x065e2082, 0x0b1d065b, 0x0fdc1bec,
0x3793a651, 0x3352bbe6, 0x3e119d3f, 0x3ad08088, 0x2497d08d,
0x2056cd3a, 0x2d15ebe3, 0x29d4f654, 0xc5a92679, 0xc1683bce,
0xcc2b1d17, 0xc8ea00a0, 0xd6ad50a5, 0xd26c4d12, 0xdf2f6bcb,
0xdbee767c, 0xe3a1cbc1, 0xe760d676, 0xea23f0af, 0xeee2ed18,
0xf0a5bd1d, 0xf464a0aa, 0xf9278673, 0xfde69bc4, 0x89b8fd09,
0x8d79e0be, 0x803ac667, 0x84fbdbd0, 0x9abc8bd5, 0x9e7d9662,
0x933eb0bb, 0x97ffad0c, 0xafb010b1, 0xab710d06, 0xa6322bdf,
0xa2f33668, 0xbcb4666d, 0xb8757bda, 0xb5365d03, 0xb1f740b4
};
unsigned long memcrc(const unsigned char *b, size_t n)
{
/* Input arguments:
* const unsigned char* b == byte sequence to checksum
* size_t n == length of sequence
*/
register size_t i;
register unsigned c, s = 0;
for (i = n; i > 0; --i) {
c = *b++;
s = (s << 8) ^ crctab[(s >> 24) ^ c];
}
/* Extend with the length of the string. */
while (n != 0) {
c = n & 0377;
n >>= 8;
s = (s << 8) ^ crctab[(s >> 24) ^ c];
}
return ~s;
}
The historical practice of writing the number of ``blocks'' has
been changed to writing the number of octets, since the latter is
not only more useful, but also since historical implementations
have not been consistent in defining what a ``block'' meant.
The algorithm used was selected to increase the operational
robustness of cksum. Neither the System V nor BSD sum algorithm
was selected. Since each of these was different and each was the
default behavior on those systems, no realistic compromise was
available if either were selected—some set of historical
applications would break. Therefore, the name was changed to
cksum. Although the historical sum commands will probably
continue to be provided for many years, programs designed for
portability across systems should use the new name.
The algorithm selected is based on that used by the
ISO/IEC 8802‐3:1996 standard (Ethernet) for the frame check
sequence field. The algorithm used does not match the technical
definition of a checksum; the term is used for historical
reasons. The length of the file is included in the CRC
calculation because this parallels inclusion of a length field by
Ethernet in its CRC, but also because it guards against
inadvertent collisions between files that begin with different
series of zero octets. The chance that two different files
produce identical CRCs is much greater when their lengths are not
considered. Keeping the length and the checksum of the file
itself separate would yield a slightly more robust algorithm, but
historical usage has always been that a single number (the
checksum as printed) represents the signature of the file. It was
decided that historical usage was the more important
consideration.
Early proposals contained modifications to the Ethernet algorithm
that involved extracting table values whenever an intermediate
result became zero. This was demonstrated to be less robust than
the current method and mathematically difficult to describe or
justify.
The calculation used is identical to that given in pseudo-code in
the referenced Sarwate article. The pseudo-code rendition is:
X <- 0; Y <- 0;
for i <- m -1 step -1 until 0 do
begin
T <- X(1) ^ A[i];
X(1) <- X(0); X(0) <- Y(1); Y(1) <- Y(0); Y(0) <- 0;
comment: f[T] and f'[T] denote the T-th words in the
table f and f' ;
X <- X ^ f[T]; Y <- Y ^ f'[T];
end
The pseudo-code is reproduced exactly as given; however, note
that in the case of cksum, A[i] represents a byte of the file,
the words X and Y are treated as a single 32-bit value, and the
tables f and f' are a single table containing 32-bit values.
The referenced Sarwate article also discusses generating the
table.
Будущие направления (Future directions)
None.
Смотри также (See also)
The Base Definitions volume of POSIX.1‐2017, Chapter 8,
Environment Variables
