Re: Wodim: How to read from stdin?

[Thomas Schmitt]

Hi,

me:
> > Just like options -sao -isosize with crskin. (The size is 
> > announced somewhere between block  16 and 31. So this is no black 
> > magic.)
Til Schubbe:
> Which means that cdrskin doesn't need to read the image as a whole
> from stdin when starting, but gets it while burning (with a
> reasonable prefetch)?

Yes. cdrskin uses its fifo to peek at the first
few kB of the image. growisofs does it similar.

That is necessary only for write mode DAO of
DVD-R[W] and SAO of CD-R[W].
With the multi-session capable mode Incremental
of DVD-R one can just start writing.
DVD+R and BD-R behave about the same.
DVD-RAM, DVD+RW, BD-RE can be freely written
in random access with 2 or 32 kB granularity.
DVD-RW can be switched between DVD-R behavior
and DVD+RW behavior.


Bill Davidsen:
> In my case I have a data stream of 400-500MB which I wish to burn to CD, but
> because I can't know the size in advance and don't wish to save it for
> reasons I won't detail, I am forced to use growisofs and DVD for these
> little data sets.

But cdrecord and wodim should be able to do this
on CD by option -tao.
Their handicap is with DVD only.


> The growisofs
> program knows how to do this for DVD but can not do it for CD (one of my
> problems).

Any reason why cdrskin does not suffice for your
purposes ? It is willing to burn CD, DVD and BD.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: cdrkit 1.1.10 fails to locate libcap

[Joerg Schilling]

Norbert Preining  wrote:

> On Sa, 02 Jan 2010, Joerg Schilling wrote:
> > Cdrkit is undistributable as it is in conflict with the GPL and the 
> > Copyright 
> > law. Cdrkit is unmaintained since May 6th 2007, so why do you ask for 
> > cdrkit?
>
> 1. This is a mailing list for CD/DVD writing, not for your personal
>enjoyment. There are other cd burning programs, and it is valid to ask 
> here.

Please stop your hostile trolling, this is a mailing list to discuss CD/DVD/BD 
writing and you did never write anything that was helpful for this topic.


> 2. Please provide proofs that it is undistributable, or start a suit
>case if you are sure that it is in conflict with Copyright law.

The proof for my statements is on my website, there os no need to repeat my 
statements at nauseum. The fact that you ingnore facts is irrelevant and just 
proves that your only interest is trolling.

Note that your mails are called "Verleundung" unless you _prove_ your claims 
with facts. So stop mailing or finally prove that the Debian fork is _not_
in conflict with the GPL and not in conflict with the Copyright law.

> If you continue like that I will request to list master to ban you from
> this and other lists hosted here.

I hope that I don't need to ask to ban you, as you are a person that is only 
known for frequent trolling. So take care and unless you have something 
substanceful stop posting to this list. 

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: Wodim: How to read from stdin?

[Joerg Schilling]

Bill Davidsen  wrote:

> This is a limitation of cdrecord and programs derived from it. The 
> growisofs program knows how to do this for DVD but can not do it for CD 
> (one of my problems). In your case you can know the size of the image in 
> advance because you have it. In fact, I wonder why you don't just burn 
> it direct.

Growisofs does not write in SAO mode, this is the reason why it can do things 
that do not work the easy way on SAO mode.

> In my case I have a data stream of 400-500MB which I wish to burn to CD, 
> but because I can't know the size in advance and don't wish to save it 
> for reasons I won't detail, I am forced to use growisofs and DVD for 
> these little data sets.

You are of course not forced to use growisofs. Cdrecord will work for you too
if you use it the right way... there is e.g. the -stream-media-size size
option for mkisofs and there are plenty of other methods.

> Mr Schilling noted that there seems a way to do this in some modes, but 
> he provides no information on it. He's probably right that it could be 
> done, but doesn't want ot say how for whatever reason.

Sorry, but this is nonsense. The way it can be done is obvious to anyone
with some basic skills in CD/DVD/BD writing. The reason why it is not yet 
implemented in cdrecord is just that there are many more important things to do
and that it would not work on all 30+ platforms that cdrecord supports.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

how to rescue this backup data

[Zhang Weiwu]

Hello. We have a website backup that has to be recovered thanks to 
webserver hard disk crash. However the person who burned the backup seems 
to have done it wrong. This is what we investigated what most likely 
have happened:


a. he have a DVD+R that has a session on it.
b. he created a backup iso image by merging that session:
 $ genisoimage -C ... -M /dev/sr0 -o backup.iso website_backup/
c. he burnt the backup to a /different/ DVD+R that also had a session:
 $ wodim dev=/dev/sr1 backup.iso
  (or, might also have been "$ growisofs -M /dev/sr1=backup.iso" )
d. he happily labeled the DVD+R in /dev/sr1 as "website backup". no 
double check. done.



Now, we have the DVD+R that was there in /dve/sr1 when he do step c, 
because it is correctly labeled as website backup. I can dump backup.iso 
by using this:

  $ dd if=/dev/sr1 of=backup.iso bs=2048 count=155440 skip=1256096
  where value of count and skip are found here
$ dvd+rw-mediainfo /dev/sr1 | grep -A 4 '.\[#2\]'
READ TRACK INFORMATION[#2]:
 Track State:   partial/complete
 Track Start Address:   1256096*2KB
 Free Blocks:   0*2KB
 Track Size:155440*2KB

We do not know which DVD+R was in /dev/sr0 when he do step b. There are 
a few hundreds in stock. We can locate a dozen that might be if really 
have to. The dumped backup.iso has the right size, that makes me believe 
nothing merged from the previous session in step b are important to me. 
In other words, backup.iso should contain all data I need to recover the 
website.


However, reasonable to believe, I could not mount backup.iso:
# mount -o loop backup.iso /mnt/
mount: /dev/loop0: can't read superblock

My question is, is there a way to recover hierarchical file backup from 
backup.iso, except all files and directories that refer to the previous 
session, which we could not easily find and should not need?


Thanks in advance!

Best.


--
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: cdrkit 1.1.10 fails to locate libcap

[Joerg Schilling]

Mark Rosenstand  wrote:

> > Cdrkit is undistributable as it is in conflict with the GPL and the 
> > Copyright 
> > law. Cdrkit is unmaintained since May 6th 2007, so why do you ask for 
> > cdrkit?
>
> The 1.1.10 source package on ftp.debian.org is dated just over a month
> ago, but yeah, it's unfortunate that it hasn't hit the upstream download
> area yet. Latest stable release of cdrtools seems to be from 2004
> though.

The fact that somebody creates new "versions" does not proof that there is 
some kind of maintenance. During the last 2.5+ years, there was much less
changes in the fork than in a very lazy week of development on cdrtools.

There are still more than 100 well known bugs in the fork that do not get fixed.
Given the fact that most of these bugs could be fixed in much less than one 
hour 
each, it is obvious that the people behind cdrkit do not care about users

Cdrkit users are on a dead end, there are no bug fixes and there is no 
development.


> > I recommend you to use the original software from 
> > ftp://ftp.berlios.de/pub/cdrecord/alpha/
>
> I've been using cdrecord for years before cdrkit appeared, but with
> cdrkit being what most Linux distros package these days, I just go with
> the flow, as it means less work/headscratching for me in the long run.

Well, you are a user and you could ask your Linux distributor why he 
distributes unmaintained software with legal problems instead of well 
maintained original software with no legal problems.

Given the fact that there have been many new features added to cdrtools since 
the time some people created the "fork", 


> I'm maintaining all packages myself, so the totally non-standard build
> system in cdrtools is a big minus, especially since pretty much all the
> default paths, permissions, and even ownership are different from what's
> casual on Linux systems today. When you have over 1400 source packages
> to maintain, automation is key. (Sorry, I don't use any of your other
> software, so I can't justify the time it will take to automate it.)

Well, cdrtools uses a standard leading edge build system. The fact that is
has extreme similarities to the build system created by David Korn that 
is written on top of a new make utility "nmake" but uses the same ideas
of just having a list of source files in the leaf makefiles verifies that
it uses the right basic ideas. In contrary to other build systems, it 
grants out of the box compilation on 30+ platforms. It may be that you 
are not flexible enough to lean new software and that you just not notice that
many of the OSS packages that use different build systems just do not compile 
even on major platforms like Solaris without manually changing significant 
parts.

And BTW: if you like automation, you should already know the advantages of
the schily makefilesystem as you just need to call "smake". The other packages
you may be talking about, force you to call "configure" manually and usually do 
not even compile unless you find out some magic parameters you need to add
to the "configure" call in order to get a usefull autoconf result. 

It may be that you are a victim of the Stickholm syndrom and like what punishes
you ;-)


> > There are no known problems with the original software and the original 
> > software
> > includes many new features that are missing from the illegal fork.
>
> This is a valid point and if GPL'ed software fails, I will likely give
> it a shot. I were turned off a bit with the whole cdrecord-ProDVD thing
> and then the CDDL issues, but at least the former seems no longer an
> issue, and e.g. BluRay writing is indeed a nice feature.

There never was such an issue. There have been some hostile people who spread
incorrect claims on my software in order to harm. 

Just in case you don't know: I was the fisrt person who tried to sue companies
for violating the GPL and while doing this, I learned that most of the GPL 
claims cannot be enforced in court. The CDDL is a license that is more liberal 
and just includes those claims that are enforcable in court. 


Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: Wodim: How to read from stdin?

[Joerg Schilling]

Til Schubbe  wrote:

> > In fact, I wonder why you don't just burn  
> > it direct.
>
> Computer A has the burner inside, but not enough free diskspace to
> cache the image, which is on computer B... But meanwhile I think
> about putting the burner into A.

One solution for this problem is the RSCSI protocol that I created 10 years
ago in order to talk to remote SCSI devices. This let's you run cdrecord
on computer B while the burner is in computer A.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: Wodim: How to read from stdin?

[Joerg Schilling]

"Thomas Schmitt"  wrote:

> Bill Davidsen:
> > In my case I have a data stream of 400-500MB which I wish to burn to CD, but
> > because I can't know the size in advance and don't wish to save it for
> > reasons I won't detail, I am forced to use growisofs and DVD for these
> > little data sets.
>
> But cdrecord and wodim should be able to do this
> on CD by option -tao.
> Their handicap is with DVD only.

wodim is unmaintained. Missing features will not appear there...

> > The growisofs
> > program knows how to do this for DVD but can not do it for CD (one of my
> > problems).
>
> Any reason why cdrskin does not suffice for your
> purposes ? It is willing to burn CD, DVD and BD.

cdrskin has less features than cdrecord and it does not work on Solaris 
(cdrskin is Linux only).

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: how to rescue this backup data

[Joerg Schilling]

Zhang Weiwu  wrote:

> Hello. We have a website backup that has to be recovered thanks to 
> webserver hard disk crash. However the person who burned the backup seems 
> to have done it wrong. This is what we investigated what most likely 
> have happened:
>
> a. he have a DVD+R that has a session on it.
> b. he created a backup iso image by merging that session:
>   $ genisoimage -C ... -M /dev/sr0 -o backup.iso website_backup/
> c. he burnt the backup to a /different/ DVD+R that also had a session:
>   $ wodim dev=/dev/sr1 backup.iso
>(or, might also have been "$ growisofs -M /dev/sr1=backup.iso" )
> d. he happily labeled the DVD+R in /dev/sr1 as "website backup". no 
> double check. done.

1)
wodim does not support to write DVDs (in special DVD+). This is bad in special
as it claims that it includes DVD support.

2)
If you have "wodim" on your system, there is a big chance that you used 
"genisoimage" (part of the fork) instead of the original software "mkisofs".
Genisoimage is known to have many bugs that in special hit you in multi-session 
mode. 

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: how to rescue this backup data

[Zhang Weiwu]

在 2010-01-03日的 15:19 +0100，Joerg Schilling写道：
> 1)
> wodim does not support to write DVDs (in special DVD+). This is bad in special
> as it claims that it includes DVD support.
> 
> 2)
> If you have "wodim" on your system, there is a big chance that you used 
> "genisoimage" (part of the fork) instead of the original software "mkisofs".
> Genisoimage is known to have many bugs that in special hit you in 
> multi-session 
> mode. 

on a practical level, is there a suggestion what we could do /now/ to
recover the website? That would indeed be very helpful.

If you need the information whether or not we used mkisofs in order to
provide any suggestion on recovering data, the answer is very likely
"no" because all computers here run debian and the previous employees
working here (who does the backup), most of them just use whatever
debian offers as part of the default installation that contains gnome.


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: how to rescue this backup data

[Joerg Schilling]

Zhang Weiwu  wrote:

> on a practical level, is there a suggestion what we could do /now/ to
> recover the website? That would indeed be very helpful.

The problem with a lot of backup methods is that it is WORN (write once, read 
never) until you need it.

People should always test their meckup method before there is a need for it.

> If you need the information whether or not we used mkisofs in order to
> provide any suggestion on recovering data, the answer is very likely
> "no" because all computers here run debian and the previous employees
> working here (who does the backup), most of them just use whatever
> debian offers as part of the default installation that contains gnome.

I recommend you to start with installing recent original software from

ftp://ftp.berlios.de/pub/cdrecord/alpha/

and then to run "isoinfo -i devname -d" in order to check thether the
medium contains a ISO-9660 filesystem at all.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

HYIP script

[Harish R]

Hello cdwrite,

I need the hyip script. Please send it through mail!

Tnx

Re: how to rescue this backup data

[Zhang Weiwu]

在 2010-01-03日的 16:05 +0100，Joerg Schilling写道：
> I recommend you to start with installing recent original software from
> 
> ftp://ftp.berlios.de/pub/cdrecord/alpha/
> 
> and then to run "isoinfo -i devname -d" in order to check thether the
> medium contains a ISO-9660 filesystem at all.

I forgot to mention in the first post that I checked the image using
strings(1). It contains all the file names I expect in the backup iso
file system so I assumed it must contain ISO-9660 file system. Correct
me if I am wrong and should double-test. It seems to be made by using
mkisofs, as the following:

> strings backup.iso | head -n 30
CD001
LINUX   www.eecz.org.cn Backup  




MKISOFS ISO 
9660/HFS FILESYSTEM BUILDER & CDRECORD CD-R/DVD CREATOR (C) 1993 E.YOUNGDALE 
(C) 1997 J.PEARSON/J.SCHILLING  
  
2007080723063000 2007080723063000 
2007080723063000 







CD001
ABOUTUS
ADMIN
ASPNET_CLIENT
CERT
CGI_BIN
CONTACTUS
DISCLAIMER
DOWNLOAD
GLOSSARY
HOME
HTTPERRORS
IMAGES
LINKS
LOTUSPOOL
MAIL
NEWSEVENTS
PHOTO
PROGRAMMEFOCUS
PROGRAMMEPARTNERS
SITEMAP
STAT
XYIZNWSK
IMAGES
IMAGES



-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: how to rescue this backup data

[Thomas Schmitt]

Hi,

> $ genisoimage -C ... -M /dev/sr0 -o backup.iso website_backup/
> $ wodim dev=/dev/sr1 backup.iso
>  (or, might also have been "$ growisofs -M /dev/sr1=backup.iso" )
> d. he happily labeled the DVD+R in /dev/sr1 as "website backup".

Wow, that's quite some puzzle to solve.

> Now, we have the DVD+R that was there in /dve/sr1 when he do step c, because
> it is correctly labeled as website backup. I can dump backup.iso by using
> this:
>   $ dd if=/dev/sr1 of=backup.iso bs=2048 count=155440 skip=1256096

If this is an ISO 9660 image then

  $ dd if=backup.iso bs=2048 skip=16 count=1 | \
od -c | less

should show this output

  000 001   C   D   0   0   1  ...
  ...

If so, then you have the task to guess the offset
value TheOffset that was used with

  genisoimage -C c1,TheOffset

You would then create a dummy file of that size
(1 block = 2048 bytes) and append the image at
its end.

  $ dd if=/dev/zero bs=2048 count=$TheOffset \
   of=prefix_file
  $ cat backup.iso >> prefix_file

Then you could mount it on Linux by:

  $ mount -o loop,sbsector=$TheOffset \
backup.iso /mnt/

Of course any reference to the first session
of the media will yield files with all 0 bytes
in them. Expect only the directory tree and the
new files of session 2 to be valid.




This would be easy if you had the DVD from sr0.

If not, then lets have a look into ECMA-119,
8.4 Primary Volume Descriptor:
 "[byte position counting begins with 1]
  157 to 190
  Directory Record for Root Directory"
9.1 Format of a Directory Record
 "3 to 10
  Location of Extent"

This value tells you where the ISO image has its
first storage chunk for directory records.
It is supposed to sit shortly after the start
of the image.

With a first session generated by mkisofs i
get (on a system with AMD/Intel byte sex)

  $ dd if=fertig.iso bs=2048 skip=16 count=1 | \
dd bs=1 skip=158 count=4 | od -d
  ...
  00028 0

The number is recorded by least significant byte
first. So the value with offset 0 is 28 blocks.
(The other four bytes up to 10 are the same
 number as MSB.)

Now obtain the value from your image backup.iso.
E.g.
  $ dd if=backup.iso. bs=2048 skip=16 count=1 | \
dd bs=1 skip=158 count=4 | od -d
  000 4015621

Compute the block number
  $ expr 21 '*' 65536 + 40156
  1416412

subtract 28 and try this as $TheOffset for above
prefix file and mount option sbsector.
  $ expr 1416412 - 28
  1416384

In case of failure, try the neighboring numbers.
The right one cannot be very far away.

You may get an impression about possible
deviations if you try this computation with
correctly recorded multi-session DVD+R.
The guess and the real track start address should
be quite near together.

With my xorriso generated images on a DVD-RW
it seems to work exactly. But mkisofs might have
other habits. (The offset itself is dictated by
the media. But the choice of first directory
address is at the discretion of mkisofs.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: Wodim: How to read from stdin?

[Bill Davidsen]

Joerg Schilling wrote:

Bill Davidsen  wrote:

  
This is a limitation of cdrecord and programs derived from it. The 
growisofs program knows how to do this for DVD but can not do it for CD 
(one of my problems). In your case you can know the size of the image in 
advance because you have it. In fact, I wonder why you don't just burn 
it direct.



Growisofs does not write in SAO mode, this is the reason why it can do things 
that do not work the easy way on SAO mode.


  
In my case I have a data stream of 400-500MB which I wish to burn to CD, 
but because I can't know the size in advance and don't wish to save it 
for reasons I won't detail, I am forced to use growisofs and DVD for 
these little data sets.



You are of course not forced to use growisofs. Cdrecord will work for you too
if you use it the right way... there is e.g. the -stream-media-size size
option for mkisofs and there are plenty of other methods.

  
This is not an ISO filesystem, before or after burning. What is needed 
is a mode to read stdin until end of data, pad as needed and close. 
There are many interesting formats beyond ISO-9660.
Mr Schilling noted that there seems a way to do this in some modes, but 
he provides no information on it. He's probably right that it could be 
done, but doesn't want ot say how for whatever reason.



Sorry, but this is nonsense. The way it can be done is obvious to anyone
with some basic skills in CD/DVD/BD writing. The reason why it is not yet 
implemented in cdrecord is just that there are many more important things to do

and that it would not work on all 30+ platforms that cdrecord supports.

  
I don't need it on 30 platforms, I need it on one. Fortunately growisofs 
provides that, since cdrecord seems not to be able to do so.


--
Bill Davidsen 
 "We can't solve today's problems by using the same thinking we
  used in creating them." - Einstein


--
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: how to rescue this backup data

[Thomas Schmitt]

Hi again,

i wrote:
>   $ cat backup.iso >> prefix_file
> Then you could mount it on Linux by:
>  $ mount -o loop,sbsector=$TheOffset \
>backup.iso /mnt/

This should of course be

   $ mount -o loop,sbsector=$TheOffset \
 prefix_file /mnt/

as backup.iso is not altered by above cat.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: cdrkit 1.1.10 fails to locate libcap

[Norbert Preining]

On So, 03 Jan 2010, Joerg Schilling wrote:
> Please stop your hostile trolling, this is a mailing list to discuss 
> CD/DVD/BD 
> writing and you did never write anything that was helpful for this topic.

And the original question was about a CD burning program.

Could you please be more specific what was "hostile trolling" here
but the fact that I want this list to be open to everyone and every
CD/DVD/BD writing software?

> Note that your mails are called "Verleundung" unless you _prove_ your claims 

"Verleumdung" (not "Verleundung")

Furthermore, it is *you* who are stating that something is against the law.
AFAIR in all the European law systems (both Latin based on the continent
and Anglosaxian based in the UK) it is still the job of the one
accusing someone to be against the law to provide proofs.

> with facts. So stop mailing or finally prove that the Debian fork is _not_
> in conflict with the GPL and not in conflict with the Copyright law.

As I said, it is *your* job to enforce that if you are so sure about it.
The German courts are open to your suitcases. I will happily follow
them and wish you good luck (not really).

But as long as you do *NOT* have sufficient proof, and putting something
on *your* websites is not "sufficient proof", in any reasonable
law system, whatever you say in this respect can be considered "Verleumdung".

> > If you continue like that I will request to list master to ban you from
> > this and other lists hosted here.
> 
> I hope that I don't need to ask to ban you, as you are a person that is only 
> known for frequent trolling. So take care and unless you have something 
> substanceful stop posting to this list. 

Good luck, would be the first time (well in fact not, but that has different
reasons) that a DD is banned from a Debian hosted mailing list.

So please, go ahead, PLEASE PLEASE PLEASE I will enjoy the fun of it!

Best wishes

Norbert

Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria   Debian TeX Task Force
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

ZAPHOD  Hey, this rock...
FORDMarble...
ZAPHOD  Marble...
FORDIce-covered marble...
ZAPHOD  Right... it's as slippery as... as... What's the slipperiest
thing you can think of?
FORDAt the moment? This marble.
ZAPHOD  Right. This marble is as slippery as this marble.
 --- Zaphod and Ford trying to get a grip on things in
 --- Brontitall, Fit the Tenth.
 --- Douglas Adams, The Hitchhikers Guide to the Galaxy


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: how to rescue this backup data (now I verified the iso image is an iso image)

[Zhang Weiwu]

在 2010-01-03日的 17:02 +0100，Thomas Schmitt写道：

> If this is an ISO 9660 image then
> 
>   $ dd if=backup.iso bs=2048 skip=16 count=1 | \
> od -c | less
> 
> should show this output
> 
>   000 001   C   D   0   0   1  ...
>   ...


ar...@jamaica:/tmp> dvd+rw-mediainfo /dev/sr1 | grep -A 3 "#2.:"
READ TRACK INFORMATION[#2]:
 Track State:   partial/complete
 Track Start Address:   1256096*2KB
 Free Blocks:   0*2KB
ar...@jamaica:/tmp> expr 1256096 + 16
1256112
ar...@jamaica:/tmp> dd if=/dev/sr1 bs=2048 skip=1256112 count=1 | od -c | head 
-n 1
1+0 records in
1+0 records out
2048 bytes (2.0 kB) copied，1.69675 秒，1.2 kB/秒
000 001   C   D   0   0   1 001  \0   L   I   N   U   X

ISO-image verified.

However problem is not solved. I will explain how it is not solved in a
following separate email to keep the discussion thread clean.



-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: how to rescue this backup data (could not get original value for mkisofs -C)

[Zhang Weiwu]

在 2010-01-03日的 17:02 +0100，Thomas Schmitt写道：
> If so, then you have the task to guess the offset
> value TheOffset that was used with
> 
>   genisoimage -C c1,TheOffset

snip...

> This would be easy if you had the DVD from sr0.
> 
> If not, then lets have a look into ECMA-119,
> 8.4 Primary Volume Descriptor:
>  "[byte position counting begins with 1]
>   157 to 190
>   Directory Record for Root Directory"
> 9.1 Format of a Directory Record
>  "3 to 10
>   Location of Extent"
> 
> This value tells you where the ISO image has its
> first storage chunk for directory records.
> It is supposed to sit shortly after the start
> of the image.

snip..

> obtain the value from your image backup.iso.
> E.g.
>   $ dd if=backup.iso. bs=2048 skip=16 count=1 | \
> dd bs=1 skip=158 count=4 | od -d
>   000 4015621
> 
> Compute the block number
>   $ expr 21 '*' 65536 + 40156
>   1416412


ar...@jamaica:/tmp> dd if=/dev/sr1 bs=2048 skip=1256112 count=1 \
  | dd bs=1 skip=158 count=4 | od -d
4+0 records in
4+0 records out
4 bytes (4 B) copied，0.122195 秒，0.0 kB/秒
000 46890  4864
004
1+0 records in
1+0 records out
2048 bytes (2.0 kB) copied，0.0360709 秒，56.8 kB/秒
ar...@jamaica:/tmp> expr 4864 '*' 65536 + 46890
318813994

This value surprised me a bit, it is unlikely even close to a possible
offset. Because:

ar...@jamaica:/tmp> expr 318813994 "*" 2 / 1048576
608

so this offset is 608GB away from beginning.

So I cannot go on from here.

Thank you very much not only by instructing me in detail but also thank
you for correctly guessed my level of background knowledge to make the
instruction not too detail nor too brief. I always appreciate someone
with communication skill like you do.

I thus doubt there are something wrong with the "superblock". I think
now what I can do is to get you dump of everything until 190, end of
volume descriptor, to see if there are something wrong. It is not
impossible that it happened to the backup operator to have typed in a
irrational value for "mkisofs -C"

ar...@jamaica:/tmp> dd if=/dev/sr1 bs=2048 skip=1256112 count=1 | od -cx
000 001   C   D   0   0   1 001  \0   L   I   N   U   X
0143 4430 3031 0100 4c49 4e55 5820 2020
020
2020 2020 2020 2020 2020 2020 2020 2020
040   w   w   w   .   e   e   c   z
2020 2020 2020 2020  772e 6565 637a
060   .   o   r   g   .   c   n   B   a   c   k   u   p
2e6f 7267 2e63 6e20 4261 636b 7570 2020
100  \0  \0  \0  \0  \0  \0  \0  \0
2020 2020 2020 2020    
120   !   _ 002  \0  \0 002   _   !  \0  \0  \0  \0  \0  \0  \0  \0
215f 0200 0002 5f21    
140  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
       
160  \0  \0  \0  \0  \0  \0  \0  \0 001  \0  \0 001 001  \0  \0 001
    0100 0001 0100 0001
200  \0  \b  \b  \0 300 002  \0  \0  \0  \0 002 300 263   * 023  \0
0008 0800 c002   02c0 b32a 1300
220  \0  \0  \0  \0  \0 023   * 265  \0  \0  \0  \0   "  \0 267   *
  0013 2ab5   2200 b72a
240 023  \0  \0 023   * 267  \0  \0  \0  \0  \0  \0   k  \a
1300 0013 2ab7 0020   2000 6b07
260 036  \v   0   ' 002  \0  \0 001  \0  \0 001 001  \0
1e0b 3027 2002  0100 0001 0100 2020
300
2020 2020 2020 2020 2020 2020 2020 2020
*
0001060   M   K
2020 2020 2020 2020 2020 2020 2020 4d4b
0001100   I   S   O   F   S   I   S   O   9   6   6   0   /   H
4953 4f46 5320 4953 4f20 3936 3630 2f48
0001120   F   S   F   I   L   E   S   Y   S   T   E   M   B   U
4653 2046 494c 4553 5953 5445 4d20 4255
0001140   I   L   D   E   R   &   C   D   R   E   C   O   R   D
494c 4445 5220 2620 4344 5245 434f 5244
0001160   C   D   -   R   /   D   V   D   C   R   E   A   T   O
2043 442d 522f 4456 4420 4352 4541 544f
0001200   R   (   C   )   1   9   9   3   E   .   Y   O   U
5220 2843 2920 3139 3933 2045 2e59 4f55
0001220   N   G   D   A   L   E   (   C   )   1   9   9   7
4e47 4441 4c45 2028 4329 2031 3939 3720
0001240   J   .   P   E   A   R   S   O   N   /   J   .   S   C   H   I
4a2e 5045 4152 534f 4e2f 4a2e 5343 4849
0001260   L   L   I   N   G
4c4c 494e 4720 2020 2020 2020 2020 2020
0001300
2020 2020 2020 2020 2020 2020 2020 2020
*
0001440   2   0   0
2020 2020 2020 2020 2020 2020 2032

Re: cdrkit 1.1.10 fails to locate libcap

[Mark Rosenstand]

On Sun, 2010-01-03 at 15:04 +0100, Joerg Schilling wrote:
> Mark Rosenstand  wrote:
> 
> > > Cdrkit is undistributable as it is in conflict with the GPL and the 
> > > Copyright 
> > > law. Cdrkit is unmaintained since May 6th 2007, so why do you ask for 
> > > cdrkit?
> >
> > The 1.1.10 source package on ftp.debian.org is dated just over a month
> > ago, but yeah, it's unfortunate that it hasn't hit the upstream download
> > area yet. Latest stable release of cdrtools seems to be from 2004
> > though.
> 
> The fact that somebody creates new "versions" does not proof that there is 
> some kind of maintenance. During the last 2.5+ years, there was much less
> changes in the fork than in a very lazy week of development on cdrtools.
> 
> There are still more than 100 well known bugs in the fork that do not get 
> fixed.
> Given the fact that most of these bugs could be fixed in much less than one 
> hour 
> each, it is obvious that the people behind cdrkit do not care about users
> 
> Cdrkit users are on a dead end, there are no bug fixes and there is no 
> development.
> 
> 
> > > I recommend you to use the original software from 
> > > ftp://ftp.berlios.de/pub/cdrecord/alpha/
> >
> > I've been using cdrecord for years before cdrkit appeared, but with
> > cdrkit being what most Linux distros package these days, I just go with
> > the flow, as it means less work/headscratching for me in the long run.
> 
> Well, you are a user and you could ask your Linux distributor why he 
> distributes unmaintained software with legal problems instead of well 
> maintained original software with no legal problems.
> 
> Given the fact that there have been many new features added to cdrtools since 
> the time some people created the "fork", 

I don't use a distribution, but the fact is that when the big distros
adopt something, it is likely to get used by a lot of people, including
e.g. CD burning GUI front-end application developers.

> > I'm maintaining all packages myself, so the totally non-standard build
> > system in cdrtools is a big minus, especially since pretty much all the
> > default paths, permissions, and even ownership are different from what's
> > casual on Linux systems today. When you have over 1400 source packages
> > to maintain, automation is key. (Sorry, I don't use any of your other
> > software, so I can't justify the time it will take to automate it.)
> 
> Well, cdrtools uses a standard leading edge build system. The fact that is
> has extreme similarities to the build system created by David Korn that 
> is written on top of a new make utility "nmake" but uses the same ideas
> of just having a list of source files in the leaf makefiles verifies that
> it uses the right basic ideas. In contrary to other build systems, it 
> grants out of the box compilation on 30+ platforms. It may be that you 
> are not flexible enough to lean new software and that you just not notice that
> many of the OSS packages that use different build systems just do not compile 
> even on major platforms like Solaris without manually changing significant 
> parts.

No doubt autotools and even cmake have their weaknesses too, but they
are much more widely used (at least in the projects I'm interested in),
so I can invest time in learning them.

Another fact is that cdrtools on Linux cannot even be built in parallel
on the world's most widely used make(1) implementation, GNU make.

Linux has a huge user base, this is usually the reason most things tend
to usually just work there. Personally I prefer the BSD's - in
particular NetBSD - to Linux because of its beautiful and elegant
design, but I use Linux out of convenience.

We are getting very much off-topic, so excuse me for not replying
further at least on this mailing list.

> And BTW: if you like automation, you should already know the advantages of
> the schily makefilesystem as you just need to call "smake". The other packages
> you may be talking about, force you to call "configure" manually and usually 
> do 
> not even compile unless you find out some magic parameters you need to add
> to the "configure" call in order to get a usefull autoconf result. 
> 
> It may be that you are a victim of the Stickholm syndrom and like what 
> punishes
> you ;-)

Again, I do not use any other software that uses your build system, so
also packaging smake would be a waste of time for me.

> > > There are no known problems with the original software and the original 
> > > software
> > > includes many new features that are missing from the illegal fork.
> >
> > This is a valid point and if GPL'ed software fails, I will likely give
> > it a shot. I were turned off a bit with the whole cdrecord-ProDVD thing
> > and then the CDDL issues, but at least the former seems no longer an
> > issue, and e.g. BluRay writing is indeed a nice feature.
> 
> There never was such an issue. There have been some hostile people who spread
> incorrect claims on my software in order to harm. 
> 
> Just in 

Re: how to rescue this backup data

[Thomas Schmitt]

Hi,

> dd if=/dev/sr1 bs=2048 skip=1256112 count=1 | od -c | head -n 1
> 000 001   C   D   0   0   1 001  \0   L   I   N   U   X

Ok.

>  dd if=/dev/sr1 bs=2048 skip=1256112 count=1 \
>   | dd bs=1 skip=158 count=4 | od -d
> 000 46890  4864
> This value surprised me a bit, it is unlikely
> even close to a possible offset.

Indeed. 4864 is much too high.

The bytes in question are:

> 220  ...  267   *
>  ...b72a
> 240 023  \0  \0 023   * 267  
> 1300  00132ab7 

man ascii ... 
Your od -d probably interprets 16 bit words MSB.
We need LSB, resp. have to read the MSB duplicate
= 0x00132ab7 :

  $ expr 19 '*' 65536 + 42 '*' 256 + 2 '*' 64 + 6 '*' 8 + 7
  1256119

That would be an offset of about 2.4 GB.
(please check my conversion of 0x132ab7 by
 a hex calculator)

So my bet is 
  1256119 - 28 = 1256091
provided that your first sessions show
  1c00 
at byte 158 (octal 0236) of block 16.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: how to rescue this backup data

[Thomas Schmitt]

Hi,

it comes to me that 1256091 is not a probable
exact start address. It should at least be
divisible by 16.

A multi-session DVD+R by xorriso looks like:

TOC layout   : Idx ,  sbsector ,   Size , Volume Id
ISO session  :   1 , 0 ,739194s , UPDATE_HOME_2008_06_22_191945
ISO session  :   2 ,741392 , 20333s , UPDATE_HOME_2008_06_25_190436
ISO session  :   3 ,763936 , 19565s , UPDATE_HOME_2008_06_29_001832
ISO session  :   4 ,785712 , 30291s , UPDATE_HOME_2008_06_30_220849
ISO session  :   5 ,818208 , 20691s , UPDATE_HOME_2008_07_03_154909
...
ISO session  :  46 ,   2097472 , 42938s , UPDATE_HOME_2008_11_13_212828
ISO session  :  47 ,   2142608 , 18932s , UPDATE_HOME_2008_11_19_180117
ISO session  :  48 ,   2163744 , 35100s , UPDATE_HOME_2008_11_25_102435
ISO session  :  49 ,   2201056 , 46953s , UPDATE_HOME_2008_11_30_201431
ISO session  :  50 ,   2250208 , 32503s , UPDATE_HOME_2008_12_04_190853

(Note that 741392 is not divisible by 32.)


Well, check what is written in the first
sessions. Hopefully this will yield a better
number than 28. 0x17 = 23 would be nice.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

cdrtools-2.01.01a71 ready

[Joerg Schilling]

NEW features of cdrtools-2.01.01a71:

***
NOTE: cdrtools is currently in a state of a release candidate for the next
major release.  

***

*** All man pages have been rewritten for the upcomming final release **
*** Please read the man pages and report hints and proposals  **


All:

-   include/schily/stat.h now supports nonosecond timestamps in struct stat 
on AIX.

-   New autoconf test for nanosecond time stamps on AIX.

-   conf/mkdir.sh

-   conf/mkdep-aix.sh was changed to avoid warnings for #pragma weak a = b
as the IBM C-compiler calls a non "#pragma weak" cpp when called with -E

Libschily:

Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty 
xiphm...@mit.edu):

Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt 
he...@hexco.de):

Libcdrdeflt:

Libdeflt:

Libfind:

Libfile:

Libhfs_iso:

Libsiconv:

Libscg:

Libscgcmd:

Libmdigest:

Rscsi:

Cdrecord:

-   Cdrecord now is able to use -isosize even in case that the image data
is read from stdin. This makes it easier to use "mkisofs | cdrecord".


Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt 
he...@hexco.de):

Readcd:

Scgcheck:

Scgskeleton:

Btcflash:

Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric 
Youngdale):

HELIOS TODO:

-   Add the HELIOS UNICODE mapping code. This needs to be done 
at UCS-2 level for Joliet and UDF (instead of UTF-8) and only
for Rock Ridge (in case of a UTF-8 based target locale) using
UTF-8 based translations.

-   Make the Apple extensions work again with "mkisofs -find"

TODO:
-   Support correct inode numbers for UDF hardlinks

-   Support sockets, pipes, char/blk-dev specials with UDF

-   read Joliet filenames with multi-session if no TRANS.TBL
or RR is present. I am looking for a volunteer for this task!

Note that this can never be 100% correct as there is no relation
between the names on the master (UNIX) filesystem, the ISO-9660
names and the Joliet names. Only the Rock Ridge names are
untranslated with respect to the original files on the
master (UNIX) filesystem.

-   add libecc/edc for CDI and similar.


The files are located on:

ftp://ftp.berlios.de/pub/cdrecord/alpha ...

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: cdrtools-2.01.01a71 ready

[Gregoire Favre]

On Sun, Jan 03, 2010 at 11:16:40PM +0100, Joerg Schilling wrote:
> NEW features of cdrtools-2.01.01a71:

> Cdrecord:
> 
> - Cdrecord now is able to use -isosize even in case that the image data
>   is read from stdin. This makes it easier to use "mkisofs | cdrecord".

For years I used tsize="$SIZE"s with a SIZE calculated from a small
command (see attached script) : should I change it ?

Thank you very much,
-- 
Grégoire Favre, Chemin de Mallieu 15, 1009 Pully, +41 21 550 61 93 
prof -> Gymnase de Chamblandes, Avenue des Désertes 29, 1009 Pully
sip -> 310...@sip.freesip.ch  / gsm -> +41 78 765 65 00
http://www.gycham.vd.ch/~greg / netvoip.ch : +41 21 544 77 44
#!/bin/bash
if [ -z "$2" ]; then
echo "usage : $0 DVD_title DVD_dir [write speed]"
echo "That will write a DVD with video structure if there a VIDEO_TS."
echo "And without video structure if without VIDEO_TS dir"
exit
fi

TITLE_SIZE=`echo $1|wc -c`
if [ $TITLE_SIZE -ge 33 ]; then
echo "$1 is $TITLE_SIZE long (33 is the limit)"
exit
fi

UDF=`find -L $2 -size +2G|wc -w`

unlock() {
cdrdao unlock --driver generic-mmc && sleep 1
}

secure() {
RETVAL=$?
if [ $RETVAL -eq 0 ]; then
echo OK, the size is $SIZE.
else
exit
fi
}

sync

ulimit -l unlimited

if [ -z "$3" ]; then
COMCD="-speed=4 -v dev=5,0,0 -dao fs=1000m "
else
COMCD="-speed=$3 -v dev=5,0,0 -dao fs=1000m "
fi

if [ $UDF -eq 0 ]; then
COM="-f -J -r -graft-points "
VIDEO=`ls $2|grep -i VIDEO_TS 2> /dev/null   |wc -w`
if [ $VIDEO -eq 0 ]; then
OPTS=$COM
SIZE=`mkisofs -f -J -r -graft-points -quiet -print-size -V $1 
$2`
secure
else
OPTS="$COM -dvd-video"
SIZE=`mkisofs -f -J -r -graft-points -quiet -print-size 
-dvd-video  -V $1 $2`
secure
fi
mkisofs $OPTS -V $1 $2|cdrecord $COMCD tsize="$SIZE"s -
secure
else
COM="-iso-level 3 -UDF -udf -f -J -r -graft-points "
VIDEO=`ls $2|grep -i VIDEO_TS 2> /dev/null   |wc -w`
if [ $VIDEO -eq 0 ]; then
OPTS=$COM
SIZE=`mkisofs -iso-level 3 -UDF -udf -f -J -r -graft-points 
-quiet -print-size -V $1 $2`
secure
else
OPTS="$COM -dvd-video"
SIZE=`mkisofs -iso-level 3 -UDF -udf -f -J -r -graft-points 
-quiet -print-size -dvd-video -V $1 $2`
secure
fi
mkisofs $OPTS -V $1 $2|cdrecord $COMCD tsize="$SIZE"s -
secure
fi
unlock
eject /dev/sr0
sleep 1
eject -t /dev/sr0
cdDir=0
while [ "$cdDir" == "0" ]; do
sleep 1
mount /mnt/cdrom && ls -alh /mnt/cdrom && DF && umount /mnt/cdrom && 
cdDir=1
done
sleep 1
#eject /dev/sr0

OPTIONS="delete reburn exit"
select opt in $OPTIONS; do
if [ "$opt" = "delete" ]; then
RM $2
exit
elif [ "$opt" = "reburn" ]; then
echo $0 $*
exit
elif [ "$opt" = "exit" ]; then
exit
else
echo bad option
fi
done

Re: cdrkit 1.1.10 fails to locate libcap

[Joerg Schilling]

Mark Rosenstand  wrote:

> > Given the fact that there have been many new features added to cdrtools 
> > since 
> > the time some people created the "fork", 
>
> I don't use a distribution, but the fact is that when the big distros
> adopt something, it is likely to get used by a lot of people, including
> e.g. CD burning GUI front-end application developers.

Let us look at the bigger distributions:

Solaris
*BSD
Gentoo
Slackware
SuSE
Arch Linux
and many others distribute the original software.

RedHat seems to be a hostile distribution as there are extremely hostile
mails from RedHat - maybe we need to sue RedHat to let them learn that
they cannot distribute software that is in conflict with GPL and Copyright law.

On March 6th 2009 at CeBIT in the Sun booth, Debian made a binding commitment 
to distribute the original cdrtools as soon as possible and there is already a
binary packet waiting at Debian since more than half a year. Let us see whether
a binding commitment from Debian is something substancial

Ubuntu is just a Debian downstream

In case you don't know, authors of frontends for cdrtools know about the > 100
bugs in the fork and thus prefer to use the original software.


> > Well, cdrtools uses a standard leading edge build system. The fact that is
> > has extreme similarities to the build system created by David Korn that 
> > is written on top of a new make utility "nmake" but uses the same ideas
> > of just having a list of source files in the leaf makefiles verifies that
> > it uses the right basic ideas. In contrary to other build systems, it 
> > grants out of the box compilation on 30+ platforms. It may be that you 
> > are not flexible enough to lean new software and that you just not notice 
> > that
> > many of the OSS packages that use different build systems just do not 
> > compile 
> > even on major platforms like Solaris without manually changing significant 
> > parts.
>
> No doubt autotools and even cmake have their weaknesses too, but they
> are much more widely used (at least in the projects I'm interested in),
> so I can invest time in learning them.

It is interesting that you even mention cmake which creates worse results
than you get from using the so called "autotools".


> Another fact is that cdrtools on Linux cannot even be built in parallel
> on the world's most widely used make(1) implementation, GNU make.

All software that uses the Schily Makefilesystem of course can be made in 
parallel. Just try e.g. "dmake" from Sun it is even available for free for
Linux x86.

There may be a problem with GNU make. GNU make is full of bugs that are not
fixed. I did e.g. file a bug report for a coneptional bug to the GNU make
maintainers in 1998 and they accepted the bug and told me that it will take a 
bit longer to get fixed. Now 12 years have passed and nothing was fixed. The
bug I am talking about here, creates warning messages for include files that
make people believe that there is a bug in the schily makefilesystem although
the bug is in GNU make.

GNU make does not yet seem to be ready for being used as a parallel make tool.
Note that GNU make is still to dumb to separate the output of commands run
in parallel. This makes it impossible to see the relation between the error 
messages and the source files the messages are created for. I have also been 
told by other people that GNU make ignores some dependencies if in parallel 
mode and thus may fail. Given the fact that GNU make before version 3.81 even
ignores dependencies in non-parallel mode (and thus cannot be used for 
cdrtools), it seems that there is just another hidden bug that was not fixed 
correctly. 

GNU make claims to be portable to many platforms but if you try to verify this
claim, you will find that GNU make compiles on all these platforms but on many 
platforms, there is no resulting usable GNU make binary. GNU make e.g. does not
work correclty on all platforms that use  as line separator or that use 
the backslash as path name separator. This is a result of the incorrectly 
implemented parser for Makefiles in GNU make. GNU make does not work for me in 
a 
useful way on OpenVMS, MS-WIN, BeOS, Haiku, OS/2. This is why I use "smake"
as the reference make implementation as smake is working correctly on all
known platforms and as smake is cleanly written and thus may easily be fixed in 
case there is a problem. 

BTW: in case you don't know, smake is even ~ 5 years older than GNU make.

The next thing I am going to implement in smake is support for parallel makes
and you can be sure that it will work correctly ;-)

> We are getting very much off-topic, so excuse me for not replying
> further at least on this mailing list.

I don't beleive that we are off topic as what you believe seems to be a common
missunderstanding for many people and thus it makes sense to correct you in 
public.


> Again, I do not use any other software that uses your build system, so
> also packaging smake would be a wa

Re: cdrtools-2.01.01a71 ready

[Joerg Schilling]

Gregoire Favre  wrote:

> On Sun, Jan 03, 2010 at 11:16:40PM +0100, Joerg Schilling wrote:
> > NEW features of cdrtools-2.01.01a71:
>
> > Cdrecord:
> > 
> > -   Cdrecord now is able to use -isosize even in case that the image data
> > is read from stdin. This makes it easier to use "mkisofs | cdrecord".
>
> For years I used tsize="$SIZE"s with a SIZE calculated from a small
> command (see attached script) : should I change it ?

It is a new feature and as it affects padding, it may cause problems with 
DVD+ or BluRay media. We need to do some tests and then decide whether it can 
be seen as a "complete enough" solution.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: cdrkit 1.1.10 fails to locate libcap

[Norbert Preining]

On Mo, 04 Jan 2010, Joerg Schilling wrote:
> Let us look at the bigger distributions:
> 
> Solaris
> *BSD
> Gentoo
> Slackware
> SuSE
> Arch Linux
> and many others distribute the original software.

OpenSuSE 11.2 distributes cdrkit.
> 
> RedHat seems to be a hostile distribution as there are extremely hostile

So then we have the biggest three Debian/Ubuntu, RH, SuSE without
schily/cdrecord.

> mails from RedHat - maybe we need to sue RedHat to let them learn that
> they cannot distribute software that is in conflict with GPL and Copyright 
> law.

Enjoy!

Best wishes

Norbert

Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria   Debian TeX Task Force
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

`How do you feel?' he asked him.
bits of me keep
passing out.' 
`We're safe,' he said.
`Oh good,' said Arthur.
in one of the
spaceships of the Vogon Constructor Fleet.'
this is obviously some strange usage of
the word "safe" that I wasn't previously aware of.'
 --- Arthur after his first ever teleport ride.
 --- Douglas Adams, The Hitchhikers Guide to the Galaxy


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: how to rescue this backup data

[Zhang Weiwu]

在 2010-01-03日的 20:11 +0100，Thomas Schmitt写道：
> Hi,
> 
> it comes to me that 1256091 is not a probable
> exact start address. It should at least be
> divisible by 16.
> Well, check what is written in the first
> sessions. Hopefully this will yield a better
> number than 28. 0x17 = 23 would be nice.

That is kind of wired!! Because:
1256119 - 23 = 1256096

as I said, I have:

# dvd+rw-mediainfo /dev/sr1 | grep -A 4 "#2.:"
READ TRACK INFORMATION[#2]:
 Track State:   partial/complete
 Track Start Address:   1256096*2KB
 Free Blocks:   0*2KB
 Track Size:155440*2KB

So it shows the 2nd session track start address 1256096 is what you
guessed.

This means, the DVD+R that was there in /dev/sr0 /had been/ the DVD+R
that was there in /dev/sr1. It was the same disk! The backup operator
did not make a mistake.

But then why mount would not work?

Jamaica:~ # mount /dev/sr1 /mnt/
mount: block device /dev/hdc is write-protected, mounting
read-only
mount: wrong fs type, bad option, bad superblock on /dev/hdc,
   missing codepage or helper program, or other error
   In some cases useful info is found in syslog - try
   dmesg | tail  or so

Jamaica:~ # mount -o session=1 /dev/sr1 /mnt/
mount: block device /dev/hdc is write-protected, mounting
read-only
mount: wrong fs type, bad option, bad superblock on /dev/hdc,
   missing codepage or helper program, or other error
   In some cases useful info is found in syslog - try
   dmesg | tail  or so

Jamaica:~ # dmesg | tail
wlan0: authenticate with AP 00:25:86:01:8a:de
wlan0: authentication with AP 00:25:86:01:8a:de timed out
grow_buffers: requested out-of-range block 18446744073708710576
for device hdc
UDF-fs: No anchor found
UDF-fs: No partition found (1)
UDF-fs: No anchor found
UDF-fs: No partition found (1)

This is really wired. I think I should just try my luck by using:

Jamaica:~ # mount -t iso9660 -o sbsector=1256096 /dev/sr1 /mnt/
mount: block device /dev/hdc is write-protected, mounting
read-only
Jamaica:~ # ls /mnt/
1.htmlfunctions.asp   mm_menu.js
1_old.htmlglobal.asp  mm_menu1.js


So now I got my backup data.

What did I revealed? Was there a bug in kernel module for iso9660? Was
there a bug in mkisofs?

Anyway, thanks for providing necessary information that I finally got
the backup data.


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: how to rescue this backup data

[Thomas Schmitt]

Hi,

> That is kind of wired!! Because:
> 1256119 - 23 = 1256096
> as I said, I have:
> Track Start Address:   1256096*2KB
> The backup operator did not make a mistake.

So you will have to re-attach his head now 
resp. pull the needles out of the voodoo doll ?


> UDF-fs: No anchor found

This is a ISO 9660 / UDF hybrid image.

It would be interesting to see what happens if
you load it into xorriso (which ignores UDF).


> This is really wired. I think I should just try my luck by using:
> Jamaica:~ # mount -t iso9660 -o sbsector=1256096 /dev/sr1 /mnt/
> mount: block device /dev/hdc is write-protected, mounting
> read-only
> Jamaica:~ # ls /mnt/
>  ns.asp   mm_menu.js
>  1_old.htmlglobal.asp  mm_menu1.js
> So now I got my backup data.

Congrats.


> What did I revealed? Was there a bug in kernel module for iso9660? Was
> there a bug in mkisofs?

The filesystem image in the first session has
two directory trees:
The one of ISO 9660 (public as ECMA-119) and the
one of UDF (ECMA-167 plus UDF-2.60).
The one of UDF seems to be a problem to the
filesystem code in the kernel.
That is not always so. Possibly it is confused
by the second session being there. The "anchor"
is possibly searched from the end of the readable
area on media.

The second session obviously has no such problem.
Probably because it contains no UDF tree.
Multi-session and UDF may be rarely tested.

Maybe you get a better result with
  mount -t iso9660 ...
so that mount does not pick UDF as first choice.

Anyway, if it works that way then you will
see the files from the _first_ session only.
Multi-session on DVD in general is not well
supported by the Linux kernel. With CD you can
issue
  -o session=2
but that does not work with CD. 
Luckily there is
  -o sbsector=
So you just need a helper program, like
dvd+rw-tools and a bit of knowledge. 




Somewhat more comfortable would have been to
perform as superuser:

  # xorriso -osirrox on \
-mount /dev/sr0 session 2 /mnt

which would have searched for the right sbsector
and issued this command via execv()

  mount -t iso9660 -o nodev,noexec,nosuid,ro,sbsector=992400 '/dev/sr2' '/mnt'

If you are cautious you can as normal user let
xorriso just format and print the command

  $ xorriso -osirrox on \
-mount_cmd /dev/sr0 session 2 /mnt
  ...
  Volume id: 'UPDATE_HOME_2009_09_06_195015'
  mount -t iso9660 -o nodev,noexec,nosuid,ro,sbsector=992400 '/dev/sr2' '/mnt'
  $

xorriso can search for volume ids too:
  -mount_cmd /dev/sr0 volid '*2009_09_06*' /mnt

Finally, xorriso can record ACLs, equip data
with MD5 checksums, equips superblock, file tree
and overall image with MD5, does multi-session
on optical media, files and block devices (e.g.
USB sticks).
It does not allow the user to confuse disks,
because in its normal operation the whole
transaction of getting the -C values and of
applying them is done within a single program
run.

For the purpose of multi-session backup, xorriso
outperforms mkisofs by far.
This example produces a daily update session
of /home/thomas/open_source_projects and
/home/thomas/personal_mail. Before the media
gets ejected, that session gets checkread by its
now recorded MD5:

  $ xorriso -for_backup -disk_dev_ino on \ 
 -assert_volid 'PROJECTS_MAIL_*' FATAL \
 -dev /dev/sr0 \
 -volid PROJECTS_MAIL_"$(date '+%Y_%m_%d_%H%M%S')" \
 -not_leaf '*.o' -not_leaf '*.swp' \
 -update_r /home/thomas/open_source_projects /open_source_projects \
 -update_r /home/thomas/personal_mail /personal_mail \
 -commit -toc -check_md5 FAILURE -- -eject all

You can checkread the sessions at any time later
again. The checksumming survives even copying
from media to media. xorriso can search sessions
in single session copies of multi-session media.

The checksum tag blocks are recognizable outside
the ISO filesystem and they tell their original
address as cleartext. We would not have had to
guess positions from ECMA-119.

xorriso is under GPL:
  http://scdbackup.sourceforge.net/xorriso_eng.html




Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: how to rescue this backup data

[Thomas Schmitt]

Hi,

i was too negative towards the Linux kernel:

me:
> Anyway, if it works that way then you will
> see the files from the _first_ session only.

The kernel does find the most recent session on
DVD and mounts it by default.
So  -t iso9660  might well be the way to easily
mount the DVD+Rs in question.

What Linux cannot do easily on DVD is finding
sessions other than the first (by sbsector=0) and
the last one (by no option sbsector=).


More errata:

>   -o session=2
> but that does not work with CD. 

Should have been "with DVD".

>   # xorriso -osirrox on \
>-mount /dev/sr0 session 2 /mnt
> mount -t iso9660 -o nodev,noexec,nosuid,ro,sbsector=992400 '/dev/sr2'
> '/mnt'

Should have been "mount ... '/dev/sr0' ..."
(I tested the command with DVD-RW at sr2 and
 copied the outcome.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org