Re: problems writing a large file to DVD+R Double Layer disk
Hi,
> The fact that som Linux people are working against the usability of Linux
> makes you believe that there is a need for a second source?
I want to be able to follow their moves by having
own souvereignty over what is going on under my
backup program.
> What really would be needed is more people who dare to tell
> those people that they are working against linux
> and cause unneeded effort at my side.
cdrskin is not a pedagogical project.
> > I.e. no way to write a data stream of unpredicted length.
> it does not even work in packet mode in DVD-R/RW.
The appearent success with growisofs and cdrskin on
various DVD burners would need an explanation then.
About all DVDs created by the users of my backup tool
are written on-the-fly. Afterwards the users check them
by a MD5 checksum of the whole image. It verifies.
That happens since 2003.
Another empiric mountiain are all those users of growisofs
who do not have problems with its basic operation
(most use cases where option -dvd-compat is omitted).
The only way to make DVD-RW Packet fail is to _fast_ blank
a DVD-RW. Such media seem restricted to DAO.
> > > ./configure: line 21233: `for ac_header in'
> > Is this from cdrskin-0.3.4.pl00.tar.gz ?
> I did take this from your scdbackup page.....
Sigh. There is really one of those again in our ./configure.
Courtesy of autotools. Unnoticed because bash since years
silently ignores this incorrect gesture.
I only wonder why you see it in line 21233. My ./configure
has "only" 20776 lines.
I'll have to correct that via sed.
test -z 1 && for ac_header in dummy
should be a single line repair of
for ac_header in
Thanks for finding it. Sorry for my disbelieving.
> I don't believe that
> there is a will to fix bugs in this software.
Not meant as an excuse:
It is not a lack of will but a lack of control over
autotools. We have to fill some cryptic variables and
then it produces some 600+ kB of ./configure script
via the ./bootstrap command.
This problem had been repaired months ago and sneaked
back in by some new little adjustment.
autotools is accepted and it happens to work in most
cases. I am sure that i could replace it for libburn
on Linux by a simple shell script within two hours.
So for now it is only embarrassing and not crux of
the matter.
As said, it is an accepted build tool (whyever) and
thus an interface to people who maintain binary
software packages.
As long as their shell tolerates it ... (sigh again).
> > Whatever, there is no system adapter for Solaris yet.
> So why do you put effort in nonportable sofware?
libburn is intended to be portable. But of course it needs
a matching system adapter which implements the interface
that is defined for interactions of libburn and the
peculiarities of an operating system.
It is ready to be ported if there is a user willing to
test and if there are specs about how to achieve
some fundamental gestures like enumerating potential
drive addresses, obtaining SCSI address parameters or
performing a SCSI command transaction.
Best would be of course if such a user has the necessary
system knowledge to help with the adapter's implementation.
> There are at least twice as many Solaris users as users for
> all *BSDs togther.
Shouldn't they get access to libburn then ?
You would have the skills to allow them the choice.
> As I told, cdrecord is truely portable and there is a
> lot of possible things that could help...
On the levels of MMC or Linux system adapter ?
Let me know some details.
> > unpredicted track size DVD+R Packet,
> > -multi
> I will check whether it makes sense with DVD+
For -tao i just leave out the RESERVE TRACK command.
For -multi i use with CLOSE TRACK SESSION Close Function 010b
rather than Close Function 101b.
DVD+R is the only media for which i found tutorial info
in MMC-5. See 4.3.6.2.2 "The Hosts Perspective".
> It wuld make sense
> to have help with creating rpm and deb packets too.
(Cough.) Packaging is not among my sports.
But i am checking for new cdrtools every now and then
(ftp://ftp.berlios.de/pub/cdrecord/alpha is not
responding right now. I'll retry.)
> A program that does not work on Solaris is no competition for me ;-)
Help to make it one. :)
> Sorry, but growisofs is not what I would call userfriendly.
The main use case is.
>From man growisofs, EXAMPLES:
"
growisofs -Z /dev/dvd -R -J /some/files
To append more data to same DVD:
growisofs -M /dev/dvd -R -J /more/files
"
One can hardly make it more concise.
I admit it becomes more demanding if you want to make
use of its fundamental DVD writing capabilities.
-use-the-force-luke is powerful but you have to
read-the-source-luke in order to understand.
-dvd-compat is another focus of user riddling.
Have a nice day :)
Thomas
Reply to: