GNU shar utilities: 4.8 Format of synchronisation packages

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 4.8 Format of synchronisation packages

Each synchronisation package is transmitted as a file named ``.remsync.tar.gz'`, which has the format of a `tar` archive, further compressed with the `gzip` program. This archive always contains a file named ``.remsync-work/orders'`, and zero or more files named ``.remsync-work/1'`, ``.remsync-work/2'`, etc. It contains no other files. Each numbered file is actually a full, non-modified file pertaining to the hierarchy of the project, as sent from the remote site.

The ``.remsync-work/orders'` file drives the processing of the received synchronization package. This ASCII file format quite closely resembles the ``.remsync'` format, which we do not explain again here. Only the keywords and their associated parameters are different, and there is no empty keyword. The following table gives the possible keywords, in the order where they normally appear.

`format`
`title`
`here`
`remote`
`ignore`
`scan`

  All those keywords are used exactly the same way as within the ``.remsync'` file, and their format is not explained again here. They state the file format, project title, local and possibly many remote identifications and directories, zero or more ignores, zero or more scans; all of these exactly as known to the remote site who created the synchronization package. In particular, the `here` line states the originating site of the package rather than the receiving one; the receiving site should still be described by one of the `remote` lines.

`visit`

  This statement appears exactly once, and has one numeric parameter. It specifies the zero-based index in the list of remote lines above. The index identifies the receiving site, that is, the site to which this package was sent.

`copy`

  This statement appears exactly once, and has one or more numeric parameters. Each specifies a zero-based index in the list of remote lines above. All indices specify the set of all sites who where broadcasted simultaneously, at the time this synchronization package was issued. The index specified by the `visit` line should also be one of the indices of the `copy` lines. The order in which the indices are given is important, as it also establishes the order in which file signatures are listed on the `check` lines below.

`check`

  This statement may appear zero, one or more times. Each occurrence describes one file known to the project at the originating site, and there is exactly one occurrence for each known file in the project. Each `check` line has exactly n+2 parameters, where n is the number of parameters of the `copy` command. The first parameter gives a file name, relative to the top directory. The second parameter gives the file signature for this file, as computed at the originating site. For each remote site presented in the `copy` command, and exactly in the same order, each supplementary parameter gives the originator's idea of the signature for the said file at this remote site. A dash (`-`) replaces the signature for a file known not to exist.

`update`

  This statement may appear zero, one or more times. Each occurrence describes what to do with one of the ``.remsync-work/n'` files, distributed within the synchronization package. In fact, there should be exactly as many `update` lines that there are numbered files in the synchronization package. Usually, each `update` line immediately follows the corresponding `check` line, and has exactly three parameters. The first parameter gives a file name in the project, relative to the top level directory of the hierarchy. The second parameter gives a file signature which the said file should have at the receiving site, for it to be replaced safely, with no questions asked (this is the originator's idea of what the file signature was, on the receiving site, prior to its replacement). A dash (`-`) replaces this signature for a file known not to exist. The third parameter is the number n, which indicates the file ``.remsync-work/n'` in the synchronization package distribution which should replace the corresponding project file at the receiving site.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

This document was generated by Bruce Korb on July, 24 2005 using texi2html 1.76.