Castaglia - Inktomi Callout Manifest Description

Callout Manifest Description
The text ManifestFile that a callout script sees is only generated if there is at least one callout script defined. This file is a user-readable representation of the binary manifest file. The ManifestFile as seen by both BCD-side and Agent-side callouts is exactly the same.

There is one ManifestFile for each Mapping in a Job, and the manifests are deleted after the Job completes.

Example:
see example-manifest-file

Description
The object type field - the first field - values are:

DIR: directory start
END: directory end
NRM: regular file
LNK: symbolic link
HLNK: hard link

The second field, the object action field, values are:

ADD: add file
CHG: change file time to match that of manifest entry
DEL: delete file
PRM: change file permissions to match that of manifest entry

Note that there is no MOV action; a file that is renamed will be DELeted, then ADDed under the new name.

The time stamp is the modification time, not creation or access time. The UID corresponds to the owner's UID and GID. NOTE: this is ID always 0 on NT/Win2K.

Security Concern Note:
If the UID/GID is always set to 0 on the BCD scan on the NT side, then if it is unpacked by a Unix agent, the files will all owned by root. Some may be concerned for security issues (ie a file comes over SUID user and becomes SUID root). However, this not an issue since a file cannot be SUID under NT. The reason that Windows NT yields UID/GID values of 0 is because that is what stat() returns. A workaround for this would be to run the Agent at the Destination as a non-root user. Then it would fail to do "dangerous" things. However, the Agent would then be unable to set file ownerships correctly.

The CRC is only relevant for regular files and is a CRC32 of the file contents. If the file is a LNK or HLNK, there will be an additional entry to the right of the file name being the "target" of the link.

FileSys id is a CDS-given number that corresponds to the manifest number in the configured BCD staging directory, under History/Pending, where there are some files with names of dnumber. The number is the FileSys id of that Mapping (History) or Destination (Pending).

TotalSize is in bytes (this seems to be the number reported in the BCD log file).

LastEntrySize is unused.

EntryTotalSize is like TotalSize but it avoids accounting for "no change" records.