Hi,
Andreas Henriksson:
> DEB_BUILDGOPTIONS="noopt nostrip debug" dpkg-buildpackage -uc -us
> this should spit out .deb packages in /tmp/foobar containing
> non-optimized debuggage binaries.
> You install them with "dpkg -i /tmp/foobar/*.deb"
For now i helped myself with vim and make.
I will follow your advise as soon as i really need gdb. For now i am
studying source and watch my test messages.
----------------------------------------------------------------------
Theory:
Do i get it right that
heap_add_entry(struct heap_queue *heap, struct file_info *file, uint64_t key)
builds a kind of sorted list (= tree) with the files' storage addresses
as key ?
Further, does the recursive building of the tree already begin to traverse it
while it is not complete ?
This would work only if all adding of items happens in the not yet read
part of the tree. This demands a roughly monotonously rising sequence
of storage addresses while traversing the directory tree of the image.
In that case the spoilsport would be our symbolic links which bear storage
address 0 in order not to coincide with a data file's content data.
(A symbolic link is an empty ISO file with the link target stored in
a Rock Ridge field that is part of the directory tree.)
----------------------------------------------------------------------
Verification:
If i force the 0-keys to values which match the needs of my theory, then
i get extracted a tree from the xorriso image.
static void
heap_add_entry(struct heap_queue *heap, struct file_info *file, uint64_t key)
{
uint64_t file_key, parent_key;
int hole, parent;
/* ts 24 Jan 2011:
The storage address of the first file "autorun.inf" is the
lowest safe value. LBA 10849.
*/
static uint64_t high_key = 22218752;
/* ts 24 Jan 2011:
libisofs symbolic links have LBA 0 = key 0.
read_entries() assumes that directories have lower keys than
any non-directories.
*/
if (key == 0)
key = high_key;
else if (key > high_key)
high_key = key;
[... normal code ...]
Regrettably this proof-of-concept is not a general remedy, because i
had to hardcode the storage address of the first data file as start
value for the plausible addresses. (Also it is not thread safe.)
It would not be safe for general ISO images, anyway. The assumptions
are too daring. Program "flyisofs" mixes directories and data.
multi-session images of mkisofs, genisoimage, or xorriso have a
directory chunk, a data chunk, another directory chunk, another data chunk,
and so on.
If my theory is right, then libarchive's ISO code is wrong.
----------------------------------------------------------------------
On the first glimpse astounding is the state of my two unpack directories:
$ du -s bsdtar_genisoimage bsdtar_xorriso
48344 bsdtar_genisoimage
46200 bsdtar_xorriso
$ diff -r bsdtar_genisoimage bsdtar_xorriso
$
Both sum up to 48353975 bytes by ls -lR. That's 47221 kB.
The xorriso image unpacks a hardlink in install.386 and install.386/gtk
-r--r--r-- 2 thomas thomas 2189312 2011-01-21 21:12 vmlinuz
whereas the genisoimage image yields two copied files
-r--r--r-- 1 thomas thomas 2189312 2011-01-21 21:12 vmlinuz
Reason could be our Rock Ridge PX entries with inode numbers.
----------------------------------------------------------------------
I will ponder whether i can deliver symbolic links with LBAs that
match libarchive's expectations.
But honestly, those expectations should rather be dropped.
George Danchev:
> This entry sequencing smells as an assumption to me.
It would be ok. xorriso does a similar sorting when extracting files,
because random access seeking on optical media is darn slow.
Only that it is not so optimistic to begin single-pass traversing
a not yet complete tree and risking to not visit some branches or
leafs.
The comment you found does not mention the daring assumption about
LBAs of directories always being lower than LBAs of other files.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
