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

Re: New tool for packing files into an ISO image



Hi,

> > Meanwhile 12 years old is my scdbackup.

> Didn't come across that in my googling. I'll be sure to add
> a pointer to it in my references.

Did you already have a look at my newer project xorriso and its
emulation modes xorrisofs, xorrecord ?

One can run xorriso's native command line interface in dialog mode
as slave at a pair of pipes. This would allow to build the ISO 9660
tree interactively with adding and deleting of files, to get quick
upper and lower size estimations, slow exact size predictions,
and to finally directly burn the resulting tree to optical media or
disk files.
There is also a C API implemented in libisoburn for direct access to
xorriso's command line options.

Said that, i have to mention debian-cd as an ISO packer. It composes
the Debian installation image sets. 52 CDs, or 9 DVDs, or 2 BDs.
Steve McIntyre is the developer.


> The way I was planning to use it was just to get some
> files off my disk and onto backup,

Ah. Now i understand the intention and use case.

Would you be interested in writing only a part of the medium at the
first run and to later add more files ? (Aka "multi-session".)

There is a certain overhead by the fact that the directory tree entries
have to be written again with each session. E.g. 40,000 files = 14 MB
of tree entries.
But you would not be obliged to always fill a whole medium at once.


> (after verifying the backup)

xorriso can write MD5 checksums into non-file blocks of the image
and use them for checkreading without the need to access the original
files. The format is publicly documented in
  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/checksums.txt

A xorriso check run would look like this for the whole medium
  xorriso -md5 on -indev /dev/sr0 -check_media --
or like this for the single files
  xorriso -md5 on -indev /dev/sr0 -check_md5_r SORRY / --


> I'm counting on -print-size to be the accurate number.

It would be a bug, if it was not exact with mkisofs, genisoimage,
or xorrisofs.
With burn programs cdrecord, xorriso, and cdrskin you have to explicitely
disable padding, in order to only write the ISO image.
growisofs never padded by default. (Because it does no CDs.)


> I was coming at this from the point of view of backing up files
> and keeping them stashed somewhere, so I didn't think it likely
> anyone would be using rewritable media,

At some point in the lifecycle of your data you might want to
make them unreadable. E.g. after having copied them to newer media
or a larger hard disk.
A few write runs with hard-to-predict content should make it very
hard to read the old data.

To my experience, BD-RE are simply more reliable than BD-R.
I used three BD burners and one BD reader so far. They all showed more
problems with reading BD-R than with reading BD-RE.


Have a nice day :)

Thomas


Reply to: