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

Re: mkisofs aborts but exit value is 0



Hi,

> Joerg Schilling wrote
>> of star-1.4.3 and online in
> Any reason to test a version that is outdated since more than 3 years?

It was the youngest star-* archive which i could spot in
  ftp://ftp.berlios.de/pub/star
I did not explore the "alpha" directory.

I'll use star-1.5a64 for the rest of my tests.


> afio is no real alternative to star for many reasons:
> 
> -	Damaged CPIO archives are much harder to recover than
> 	tar archives.

afio does a good job with that.

It can extract most files from a purposely damaged
afio-style compressed archive on disk.
If i try to read the second CD of a multi-volume set
without previously reading the first one then it needs
only a few kB to get back on track.

Lisa Simpson's voice:
  Come gather 'round children 
  it's high time ye learns
  'bout a hero named Afio
  and a devil named Burns.


> -	The POSIX cpio format is limited to 8 GB files.
> 	The SVr4 cpio format is even limited to 2 GB files.

I urge my users not to store files larger than 2 GB
in any backup format. Such a size makes readability
questionable. Not only because of the reader software
but also because of the rest of the reading system's
infrastructure.

At the user's wish my software splits large files into
several <2GB pieces.
This might become inconvenient at restore time but
such big files can hardly occur in big numbers so
it is not too much work to concatenate their pieces.

Nevertheless, if one wants to transport >=2GB files,
then star is indeed preferrable over afio.
I will mention that in my docs.


> -	Every time afio encounters files that cannot be
> 	processed with existing cpio archive formats, it
> 	changes the archive format (on the fly) to a nonstandard
> 	afio proprietary format that cannot be processed by
> 	any other archiver.

Yes. One needs to use afio to unpack afio archives.

Users should plan at backup time where to get afio in
case of total loss of system software.
(I will get it from my SuSE DVD)

To restore a completely destroyed system is an
open-end adventure anyway.
The scenario of a complete restore of all system files
is suitable mostly for server farms where identical
replacement hardware is available. 


> If you like to do backups, this is a really bad method.
> 
> For reliable backups, the backup utility needs to have full control
> over the directory tree. This is not true in case you prepare the
> filenames from another program.

Well, in this scenario my own software is the backup
utility and star is the media image formatter (like
afio, mkisofs, zip or whatever).
My software gnaws quite a while on the tree before it 
issues a plan how to format and write the backup volumes.
(Quite independent of the actual data format and the writer.)

I know, star can do much more than just formatting an 
archive.
But i need only this feature for my purpose
which is to produce backups which consist of
possibly quite many (preferrably independent)
CDs or DVDs.

 
>      0    All files were processed successfully.
>      -2 / 254
>           One or more files could not be processed successfully.
>      -1 / 255
>           Command line parsing error.
>      >0   Other positive exit codes: The errno of the  call  that
>           caused the fatal error.

Very good. It's rare that command line utilities
specify their exit values.
I meanwhile had found that  exit(-2);  in star.c
and dared to make my wrapper handle  254  as
a non-perfect but overall successful program run. 


>> Next i plan to learn about the incremental features.
>> Not so much for using them but for comparison with my
>> own incremental efforts. 
>> (Imitation is the highest form of flattery.)
> 
> star-1.4 does not support incrementals.
> with cpio, or a similar program, this is not possible too.

But with scdbackup it's possible :))
Incremental ISO, incremental afio, incremental star-1.4 ...
on a file-by-file level, not on a rsync level.

Nevertheless one has to warn users of the increase in
complexity which is caused by an incremental backup
scheme.
It is very convenient at backup time but may cause
a lot of extra work at restore time.  

On the other hand if the full backup consists of 60 CDs
and lasts two days then incremental backup is the only
chance to make frequent backups.


> GNU tar is not reliable enough for backups.

So i made no mistake to leave it out.
The tar family got quite a lot of black sheep. 


>> There's a nice feature with afio. It offers a file-by-file
>> compression with cleartext archive structure.
>> Very rugged, quite economic.
> 
> Again: star does not implement things that cannot be implemented 
> in a reliable way. To do this, you need to knoe the compressed
> size of all files before you start to archive them.

Or you need a fallback in case that a reasonable
estimation failed.

My software counts the stream which is going from
formatter (e.g. afio) to writer (e.g. cdrecord).
If the preset limit is exceeded, my software ends
the writer properly while pausing the formatter.
The user gets prompted for a new media, the writer
is started newly and the formatter is allowed to 
deliver the rest of its stream. 
(That's why i prefer to use cdrecord TAO or growisofs
 over cdrecord SAO)

Of course the two (or more) resulting media are not
independent any more, so this fallback is not very
desirable.
Proper concatenation can be done by help of one
of my programs of by help of dd. One needs to know
the split size limit, though. (650m for CD, 4480m for DVD)


> If you compress a copy in /tmp, you are limited with the size
> of the files. If you do it "on the fly", you would need to compress
> the file two times and still run into big problems when the file
> changes meanwhile.

I've chosen the third alternative: Daredevil Light.
I estimate the size of the outcome and am prepared
for the rather rare case that my estimation was too
sparse.

For the faint-hearted there is indeed an alternative
size prediction mode, which really runs all files
through gzip in order to estimate their size in the
compressed volume. But that's annoyingly slow and still
not 100 % exact.

Anyway, compression is nearly a must with large backups
of system oriented files. Sysadmins tend to hate waste of
media and of time. Especially if they have to change the
media every few minutes.
With DVD, compression may well spare you any media change.


> For long time backups, you should not use a program like afio
> that uses a proprietary achive format.

I have no doubt that i will be able to find a
copy of afio if i need one.
With Google "afio" i would just have to distinguish between 
"freshmeat.net: Project details for afio" 
and 
"Association of Former Intelligence Officers".

Googling for "star" is a bit more demanding. 
I needed a minute to find a copy.


>> On most user filesytems, ACLs and Extended Attributes are 
>> disabled, anyway.
> 
> ACLs are enabled by default on the UNIX file system since 
> more than 10 years and cannot even be switched off.

At least for SuSE Linux it is necessary to add options
to /etc/fstab . This is specific to the particular file
system type. With reiser or ext2 this would be option "acl".


Have a nice day :)

Thomas



Reply to: