[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] libcdio treats a >4GB ISO-9660 file as 2 separate pa

From: Thomas Schmitt
Subject: Re: [Libcdio-devel] libcdio treats a >4GB ISO-9660 file as 2 separate parts
Date: Thu, 24 Aug 2017 19:12:00 +0200


there is a value defined in include/cdio/iso9660.h
    ISO_MULTIEXTENT     = 128,   /**< Not final entry of a mult. ext. file */
which is not used anywhere in the source tree.


It seems that merging the directory records of a file should be done
in lib/iso9660/iso9660_fs.c function _iso9660_dir_to_statbuf().

But the API definition of struct iso9660_stat_s in include/cdio/iso9660.h
is insufficient:
  uint32_t           size;            /**< total size in bytes */

One would either need to change this to e.g. off_t with Large File Support
or to uint64_t, or one would have to chain these structs.

In practice, multi-extent files have their blocks in one large interval
with no gaps of byte addresses or block addressses. (I dimly remember to
have seen this as prescription in ECMA-119, but cannot find it now.)


If this could be solved somehow, then i'd propose the following approach:

If _iso9660_dir_to_statbuf() sees non-zero
  p_iso9660_dir->file_flags & ISO_MULTIEXTENT
then it should assert that
is divisible by 2048. Else we don't get a seamless concatenation of File
Sections with the single-struct approach, or unaligned block reading with
the chained-struct approach.

It or its caller would have to memorize that it saw ISO_MULTIEXTENT.

If the single-struct approach is taken, then the next call it would have
to suppress the calloc() in
  p_stat          = calloc(1, stat_len);
in favor of
  p_stat = <p_stat as used in previous call>;
It must verify that the new p_iso9660_dir->lns is the next block after
the end of the previous extent (old ->lns + ->size / 2048).
It should not overwrite most of the p_stat components but nevertheless do
  p_stat->size   += from_733_with_err (p_iso9660_dir->size, &err);
I do not see any other component which would be allowed to differ from
the value read from the first directory record of a file.
After the sanity checks about alignment and continuity of the extents,
the large file can be read from the first block of the first File section
up to its accumulated size.

In the chained-struct approach one would just append the completely read
new struct to the previous one.
When reading the file, libcdio will have to switch to the next struct
when the previous one is exhausted.

Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]