[Debburn-devel] schilyutils upload
Thomas Schmitt
scdbackup at gmx.net
Wed Aug 12 16:13:33 UTC 2009
Hi,
i now read
http://atterer.net/jigdo/debian-jigdo-mini-howto/x157.html#THE.TEMPLATEFILE
Steve McIntyre wrote:
> * contents of files that we know about (i.e. listed in the -md5-list)
> are referenced by checksum in the .template file instead of being
> included directly. The md5->filename lookup information is stored
> in the .jigdo file.
This would be easily done immediately before
image generation but independently of it.
We will have MD5 computation in the next release
of libisofs, anyway.
I understand -jigdo-map defines a prefix
for paths which match a certain pattern.
Are there more than one -jigdo-map option
allowed ?
> * any other data that does not match known files is compressed and
> stored directly in the .template file (e.g. filesystem headers,
> directories, padding)
This can be done before image generation if
it is not important to record exactly the same
file content as in the image in case of race
conditions with changing files on disk.
What compression algorithm is to be used ?
Is there a description which is a bit more
detailed than this one in the jigdo howto ?
.template: |xxxx| md5-0 |xx| md5-1 |xxx|cccccccc|x| md5-3 |xxxx|
> I hooked into mkisofs/genisoimage by simply
> targetting all the places that write to the
> output ISO image,
If it is only about the content bytes
of regular data files, then this happens
at
int filesrc_writer_write_data(IsoImageWriter *writer)
in
libisofs/filesrc.c
But in my eyes it is cumbersome to deduce the
file path, decide about its jigdo fate (data
in template or not) and to write to the hard
disk while one is at the same time reading
from hard disk to generate the image stream
which goes directly onto media ... (wheeze).
A main problem is to make the jigdo option
parameters available to the file content
writer object. Lots of up-wiring through
the object hierarchy might be needed.
My idea is to rather traverse the directory
tree and perform these tasks before image
generation begins.
This implies to read the file data twice but
it would avoid any interference with ISO image
generation.
(I confess to have bloated
filesrc_writer_write_data() recently by adding
MD5 content checksumming.)
My idea would be implemented as libisofs API
function which gets the jigdo parameters
as function parameters. To be run by the
application immediately before image generation.
> I'm more interested in using/adding hfs hybrid
Ouch.
We planned to implement UDF for the video
players ... but HFS ? Can't they read ISO ?
Are there important use cases ?
Have a nice day :)
Thomas
More information about the Debburn-devel
mailing list