Re: Strange behaviour of growisofs -Z option
growisofs -Z $DEV -R -J $FILE_TO_BURN
if [$? != 0 ]
then
severe_error
RETVAL=1
fi
}
"severe_error" is my error handling routine, coming from another script
which is "sourced" by the burning script.
Okay.
Now, if I run this script on a newly formatted (in "restricted" mode)
support, everything is fine.
But if I run this script again, on the same support, freshly burned,
1- I get a lot of mkisofs errors complaining about too long file names
("Joliet tree sort failed. The -joliet-long switch may help you") ;
growisofs prints mkisofs command line. How does it look like?
2- growisofs aborts in a strange manner : I get :
:-( write failed: Input/output error
It aborts because mkisofs didn't send anything. growisofs treats all
input shorter than 64K as I/O error.
severe_error: command not found
on console and my script continues because RETVAL is still at 0...
??? If "severe_error: ..." message comes from if [$? != 0 ], then how
come RETVAL is 0?
Questions :
- why mkisofs is concerned by the "-Z" option ? I thought "-Z" means
"destroy previous datas, write new".
-Z is growisofs private option and is not [should not be] passed to
mkisofs. Examine the mkisofs command line printed by growisofs at startup.
It looks like mkisofs tries to expand
my .gz, then the files and folders inside the tar's, ending with the error
shown above ;
mkisofs doesn't do that [nor does growisofs]...
- what's about growisofs and error management ?
growisofs acted as expected: no input -> I/O error...
The *only* trick I have found is to always force a full format (one
hour...), then a format on restricted mode, then burn...
Can you really confirm that you tried to record *very* *same* directory
tree prior and after full re-format? Is there possibility that it was
possible to record after re-format because of changed in the tree or is
was a different tree? Point is that the problem report doesn't make very
much sense... A.
Reply to: