Hi, > It seems that I have been cicked out from this list by Debian.
Indeed ?! That would be a very unwise and critic-worthy move. [email protected] is a place where one can meet you and Andy if there are problems with the two main burner apps on Linux. This place came in very handy. Quite calm, few spam, no persistent trolls, ... Be so kind and try a re-subscribe here. If you really are banned, then the deciders should state this publicly, please. I mean, one thing is to cease cooperation, the other is to exclude you from public technical discussion. And this i say with all the roles which stick to me right now - developer of scdbackup, who recently asked the Debian cdrkit project for migration hints about wodim. (scdbackup uses cdrecord as default, but will support wodim and already does support cdrskin under their real names.) - developer of cdrskin which tries to provide a second source for the services traditionally provided by cdrecord. - co-developer of libburn.pykix.org, which *really works* for cdrskin ... a bit by accident, as i found out meanwhile. (Well, this shall change. The accident - not the work.) To the public: I am Joerg Schilling's user, i am his imitator, i am his competitor. And look: here are two CD-germans who can still talk politely to each other. It is not impossible. Currently i want to believe in some accidental misunderstanding. (Nevertheless this letter goes as copy to Joerg directly.) > If you like to help me testing, please check the latest > cdrtools-2.01.01a13 > ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a13.tar.bz2 Well, compiling cdrecord on SuSE 9.0 is a bit cumbersome ... > completely reritten command line parsing and with the new find(1) features. ... but that should indeed be tested. You could help me with that - and help my users - by providing a Linux binary as portable as cdrecord-ProDVD was. (How do you make that thing run on SuSE 9.0 and on SuSE 7.2 ? I need to compile static to achieve this. libc problems.) > Note that the latst mkisofs now suopports find(1) expressions > similar to star(1) via libfind. I misuse it as archive formatter for backups, as i confessed earlier. Thus i am mainly interested in making regression tests wether the traditional core functionality is still ok. I would have wishes towards mkisofs, but they are a bit exotic. Number 1: A pathspec which allows to graft in the output of a program run. Defining target name in ISO image, maximum size, even RockRidge attributes, and the program command line. The size of output should be padded or truncated by mkisofs to fit the announced size. This i would use to chop oversized files (>650 MB, >=2 GB) without the need for buffering the parts on disk. (I will be able to tell exact sizes in advance.) This feature would also allow very interesting stunts like file-by-file compression and/or encryption in a plain ISO tree. Number 2: Copy the attributes of implicitely given directories into the RockRidge extensions (and/or Joliet). My problem is with a pathspec like this one (option -R is set): /pics/animals=/home/user/pics/animals I get exactly copied the rwx-permissions of "animals". But its boss directory "pics" in the ISO image gets default permissions. RTFM tells me that i can explicitely set the default mode for directories by -new-dir-mode. But rather i would need an automat which copies the actual mode from "pics". That is because scdbackup does not master a well prepared CD publication but backups to a heap of CDs what it can find on disk. No assumptions about the beauty of that tree allowed. (I warn people of using ISO for operating system snapshots.) Joerg, we'll stay in touch. Although two of above three roles submit themselves to strict chinese walling towards cdrecord source code. No peeking. I will ask you - if i know a good question. :) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
