Don Cragun <don.cragun at sun.com> wrote:
> I'm sponsoring this case for Cynthia Eastham.
>
> Since this case follows the same general practices used when sparse
> file support was added to the pax archiving utility, I'm marking this
???
AFAIK, the "pax" implementation that comes with Solaris does not support
sparse files.
> case as close approved automatic. If any members believe this needs to
> be promoted to a fast track let me know.
I see many small problems that need to be adressed before an implementation
starts.
> Template Version: @(#)sac_nextcase %I% %G% SMI
> This information is Copyright 2008 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
> Add sparse file support to cpio
> 1.2. Name of Document Author/Supplier:
> Author: Cynthia Eastham
> 1.3 Date of This Document:
> 21 November, 2008
> 4. Technical Description
> 4.1 Details
>
> PSARC case 2006/331 (Add holey file support to pax) created
I did never see such a case and the Sun pax man page does neither
include "hole" nor "sparse".
> This case adds similar sparse file support to the cpio utility.
Similar to what?
> In pass mode, (cpio -p), sparse files will be recreated at the
> destination with the same holes that were present in the source
> file, as long as the source file system supports reporting
> holes (as described by PSARC case 2004/770) and the destination
> file is seekable. Otherwise, holes in sparse files will be
> filled with '\0' btyes in corresponding destination files as
> they are now.
How do you intend to switch between the sparse support mode and the non-sparse
mode in "copy mode"?
> In copy out mode (-o) the following new option arguments to the
> cpio -H option will be added to provide sparse file support:
> ascii_sparse - assumes -c is specified. Only available
> in copy out (-o) mode.
> odc_sparse - assumes -H odc is specified Only available
> in copy out (-o) mode.
Adding sparse file support does not introduce a new archive format unless you
create a new archive format that may be detected by reading the first archive
header from a random archive.
If you like to avoid to to introduce a new option, you would need to document
this as a dirty hack. BTW: Where is the new man page?
...
> The following will apply when either '-H ascii_sparse' or
> '-H odc_sparse' is specified with -o:
> - The c_mode field will in the archive header will
> indicate that the file is a sparse file. In the old
> stat structure, the mode field is an unsigned short
> (16 bit) field. To avoid conflicts with other file
> types, a high order bit (17) in the c_mode field of
> the header will be set.
This is beyond the cpio specs. How do you plan to mark the archives
as "Sun cpio" specific to allow to avoid incorrect behavior for non-Sun
archives?
> - the file size field of the header will be the size of
> the compressed sparse file (i.e., the size of the
> header below plus the size of the file contents after
> removing the holes).
OK
> - A string of the following format will be prepended to
> the compressed file data:
> "%lu %llu%s", prepended_info_size,
> expanded_file_size, data/hole_offsets
Is this data _inside_ the file data area or is it in conflict with the
cpio extensions from David Korn and Glenn Fowler?
> where data/hole_offsets contains 2 or more entries of the
> following format:
> " %llu %llu", data_offset, hole_offset
If you ever like to debug this, I would recommend to use:
" %llu,%llu", data_offset, hole_offset
to make the data parsable by human eyes..
But why don't you follow existing other implementations that use
offset/numbytes pairs for data chunks? This results in a lower archive size.
> When the c_mode field is set, cpio will detect the sparse file
> upon file extraction, and use the prepended sparse file
> information to restore the holes in the file if the
> destiination file is seekable. If the destination file is not
> seekable, the sparse file information will be used to fill the
> holes with '\0' bytes. Archivers that do not recognize the
> sparse file mode bit will restore the compressed file and its
> prepended data as a regular file.
As it is unlikely that the first file in an archive is a sparse file, how
do you intend to detect an archive that contain this Sun specific cpio
extension?
How do you intend to switch between the sparse support mode and the non-sparse
mode in "extract mode"?
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
