On 05/18/10 04:11 PM, [email protected] wrote:
On Tue, May 18, 2010 at 03:38:47PM -0500, Shawn Walker wrote: ...4.3.8. Package Archive Index Specification: The pkg(5) archive index file enables fast, efficient access to the contents of an archive. It contains an entry for all files in the archive excluding the index file itself in the following format (also referred to as index format version 0): <name>NUL<offset>NUL<entry_size>NUL<size>NUL<typeflag>NL <name> is a string containing the pathname of the file in the archive using only ascii characters. It can be up to 65,535 bytes in length. <offset> is an unsigned long long integer in string form containing the relative offset in bytes of the first header block for the file in the archive. The offset is relative to the end of the last block of the index file in the archive they are listed in.Just trying to make sure I understand this. The ustar header gives you the offset and the size for the first archive index. The last entry in the archive index must point to another index, if one exists. The index files are zero padded to 256 bytes.
Yes, except that I want to be clear the compressed index file (if it doesn't contain an entry for another index file) is what has an additional 256 bytes of zeros appended.
In other words: ---------------------- | index.file.gz | ---------------------- | 256 bytes of zeros | ----------------------
If you have multiple archive index files, how do you find the next index without scanning through the first index? Is this possible, or have I misunderstood part of how this works?
Correct, you have to scan through the first index file to find the next index file. I didn't think that really mattered though since the client's going to want to do that anyway to determine the offsets of every file it's looking for. As a matter of convention, I could simply rewrite the first index file and ensure that the first entry is the next index file.
Realistically, I don't expect this to be used that often. For optimal access to the archive, there should really only be one index file (especially if you were performing remote, selective extraction). I only added the ability to chain the index files to make fast additions to an existing archive possible or to possibly support a split-but-complete archive functionality in the future.
When you're adding files to an archive, is it ever possible for the new index file to reference files that are already present in the archive?
No. ...
5.4. Client and Depot Support for On-Disk Archive Format: The pkg.server.repository module will be updated to support the serving of a repository in readonly mode using a pkg(5) archive file. The pkg.client.api transport system will be updated to support the usage of a pkg(5) archive file as an origin for package data. When multiple origins are present for a publisher, they will be checked in this order of preference for package data: - local client cache - pkg(5) archive files - remaining origins and mirrorsI'm okay with specifying that the local client cache is accessed first; however, I don't think it's appropriate to define the order in which any mirrors and origins will be accessed. This should be handled by the quality measurement system in the transport.
This is really talking about what happens with _action_cached() so, at the moment, is actually no different from what's in the gate (except the archive files bit).
Cheers, -Shawn _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
