Re: Wodim: How to read from stdin?
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
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?
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
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
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?
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?
"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
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
在 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
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
Hello cdwrite, I need the hyip script. Please send it through mail! Tnx
Re: how to rescue this backup data
在 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
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?
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
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
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)
在 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)
在 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
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
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
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
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
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
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
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
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
在 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
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
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