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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
