Re: Unidentified subject!
Thomas Schmitt [EMAIL PROTECTED] wrote: Joerg Schilling: growisofs uses mkisofs! Mkisofs is definitely not designed to work on a dataset that changes while mkisofs is running. [...] Growisofs cannot give you more than cdrecord gives you with pipes. How about this gesture: star -c -xdev -acl -link-dirs level=0 -C / . \ | gzip | growisofs -Z /dev/sr0=/dev/fd/0 To be checkread by: gunzip /dev/dvd | star -t -v (If this shall produce a system recovery backup then it has to be done in single user mode resp. from a booted rescue system.) Well the original claim was that cdrecord cannot work on data that is piped into cdrecord from mkisofs. This claim is definitely wrong. How would above gesture look with cdrecord for DVD media ? (No disk buffer, single pass, ready for making use of star's fault tolerance options ...) Without filesystem snapshots even star cannot guarantee consistent backups. Adding packet writing modes for DVD media is on the TODO list but with lower priority than other tasks. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
Bill Davidsen [EMAIL PROTECTED] wrote: I recommend you to read the documentation from cdrtools to learn that your claim is not true: cdrecord of course can burn from a pipe. To be more correct, cdrecord can not burn from a pipe with anything useful writing the pipe, while growisofs can. cdrecord requires that the You seem to have an narrow and incorrect sight of the world In the same narrow minded manner, I could claim that you cannot do anythign useful with growisofs (see below.). total size of the data be known before starting, which means that the usual benefits of using a pipe are not possible: * avoid having to write an image to disk when space is tight * allow overlapping of image creation and burning time * allow burning data which changes in size between observation This is if course not true, see below for more information. So if you can't know the exact size of the image before you start, you can't burn from a pipe. Actually, I don't think you can burn at all with dynamic data, there are old posts here indicating that even using the builtin mkisofs, if the files are growing there can be problems. The final size can be on the command line or in the ISO image, but must be known at the start of the burn. See the man page isosize and tsize= descriptions. The latter explains that cdrecord uses modes which require the information early. It seems that you are uninformed - sorry but growisofs uses mkisofs! Mkisofs is definitely not designed to work on a dataset that changes while mkisofs is running. Whether you _believe_ that you have been able to write something useful with growisofs, while the dataset mkisofs is working on changes, is irrelevent. In most cases, the resulting DVD will be just unusable or mkisofs will even _abort_ because a file did change it's size between the creation of the metadata part of it's output and the time when reading of the related file. CONCLUSION: growisofs _may_ in some rare cases be able to create you a usable DVD, but this is nothing you may rely on. Growisofs cannot give you more than cdrecord gives you with pipes. BTW: because it is a well known problem to make backups from life filessystems, modern Operating Systems did develop filesystem snapshots. If you use snapshots, there are no problems with _both_ growisofs _and_ cdrecord and this is the only _reliable_ way to use pipes with mkisofs on life filesystems. If you do not run a modern OS and thus lack snapshots, I recommend you to upgrade to a modern OS that supports snapshots. Both Solaris and FreeBSD support filesystem shapshots since ~ Y2000. The only other reliable way to do streaming backups from filesystems is to use the method from the time _before_ filesystem snapshots have been introduced: - Bring you computer down to single user mode - Make the backup from a now stable filesystem - Bring the system back to multi-user mode If you are on an older OS and cannot upgrade to a recent OS, this is the only way you may do backups. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
Hi, Bill Davidsen: * avoid having to write an image to disk when space is tight * allow overlapping of image creation and burning time * allow burning data which changes in size between observation Joerg Schilling: growisofs uses mkisofs! Mkisofs is definitely not designed to work on a dataset that changes while mkisofs is running. [...] Growisofs cannot give you more than cdrecord gives you with pipes. How about this gesture: star -c -xdev -acl -link-dirs level=0 -C / . \ | gzip | growisofs -Z /dev/sr0=/dev/fd/0 To be checkread by: gunzip /dev/dvd | star -t -v (If this shall produce a system recovery backup then it has to be done in single user mode resp. from a booted rescue system.) How would above gesture look with cdrecord for DVD media ? (No disk buffer, single pass, ready for making use of star's fault tolerance options ...) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
Joerg Schilling wrote: Bill Davidsen [EMAIL PROTECTED] wrote: I recommend you to read the documentation from cdrtools to learn that your claim is not true: cdrecord of course can burn from a pipe. To be more correct, cdrecord can not burn from a pipe with anything useful writing the pipe, while growisofs can. cdrecord requires that the You seem to have an narrow and incorrect sight of the world In the same narrow minded manner, I could claim that you cannot do anythign useful with growisofs (see below.). total size of the data be known before starting, which means that the usual benefits of using a pipe are not possible: * avoid having to write an image to disk when space is tight * allow overlapping of image creation and burning time * allow burning data which changes in size between observation This is if course not true, see below for more information. You ignore the first case, I assume you agree it is correct. You ignore the 2nd case, I assume you agree it is also correct. And the 3rd case is one which is readily used, so claiming it's not true is futile. Consider: find /var/spool/ordersys/closed -type f -mnewer /usr/ordersys/lastbkup | cpio -o -Hcrc | gzip -8 | growisofs -Z /dev/dvd=/proc/self/fd/0 How do I use cdrecord in this situation? The size of the data is not known, and each run may or may not include the same files. Obviously the size of the individual files doesn't change, each run is static, but run to run isn't. So if you can't know the exact size of the image before you start, you can't burn from a pipe. Actually, I don't think you can burn at all with dynamic data, there are old posts here indicating that even using the builtin mkisofs, if the files are growing there can be problems. The final size can be on the command line or in the ISO image, but must be known at the start of the burn. See the man page isosize and tsize= descriptions. The latter explains that cdrecord uses modes which require the information early. It seems that you are uninformed - sorry but growisofs uses mkisofs! No, it does not use mkisofs when reading from a pipe. It write the incoming data to the media directly, and it need not be an ISO image at all. Mkisofs is definitely not designed to work on a dataset that changes while mkisofs is running. Other than my mention that I expected problems, mkisofs is not mentioned. The issue is that cdrecord with not read pipes and burn media unless the size of the data is known in advance. This is the only issue related to the three limitations I noted above. Whether you _believe_ that you have been able to write something useful with growisofs, while the dataset mkisofs is working on changes, is irrelevent. In most cases, the resulting DVD will be just unusable or mkisofs will even _abort_ because a file did change it's size between the creation of the metadata part of it's output and the time when reading of the related file. Repeat after me, ISO images created by mkisofs are not the only data you can burn to a DVD. CONCLUSION: growisofs _may_ in some rare cases be able to create you a usable DVD, but this is nothing you may rely on. Growisofs cannot give you more than cdrecord gives you with pipes. Irrelevant. BTW: because it is a well known problem to make backups from life filessystems, modern Operating Systems did develop filesystem snapshots. If you use snapshots, there are no problems with _both_ growisofs _and_ cdrecord and this is the only _reliable_ way to use pipes with mkisofs on life filesystems. As long as a consistent dataset is written to the pipe with every run, filesystem snapshots are irrelevant. Most database applications can write a consistent dataset, not limited to just database programs like Oracle, mysql, etc. If you do not run a modern OS and thus lack snapshots, I recommend you to upgrade to a modern OS that supports snapshots. Both Solaris and FreeBSD support filesystem shapshots since ~ Y2000. See above, o/s level snapshots are not needed for database, and may actually freeze the data in the database in an inconsistent state. The only other reliable way to do streaming backups from filesystems is to use the method from the time _before_ filesystem snapshots have been introduced: - Bring you computer down to single user mode - Make the backup from a now stable filesystem - Bring the system back to multi-user mode If you are on an older OS and cannot upgrade to a recent OS, this is the only way you may do backups. Actually, as long as the backup dataset is consistent, I don't see that the method of ensuring consistency is relevant. Some are more convenient that other, I freely agree! Jörg -- E. Robert Bogusta It seemed like a good idea at the time
Re: Unidentified subject!
Joerg Schilling wrote: Rob Bogus [EMAIL PROTECTED] wrote: I think size checking is done only for ISO images. If you feed from a source, using a non-ISO image, I believe you bypass that logic. Unlike cdrecord, growisofs can burn from a pipe. I recommend you to read the documentation from cdrtools to learn that your claim is not true: cdrecord of course can burn from a pipe. To be more correct, cdrecord can not burn from a pipe with anything useful writing the pipe, while growisofs can. cdrecord requires that the total size of the data be known before starting, which means that the usual benefits of using a pipe are not possible: * avoid having to write an image to disk when space is tight * allow overlapping of image creation and burning time * allow burning data which changes in size between observation So if you can't know the exact size of the image before you start, you can't burn from a pipe. Actually, I don't think you can burn at all with dynamic data, there are old posts here indicating that even using the builtin mkisofs, if the files are growing there can be problems. The final size can be on the command line or in the ISO image, but must be known at the start of the burn. See the man page isosize and tsize= descriptions. The latter explains that cdrecord uses modes which require the information early. Last tested on 2.01.01a30 on both 2.4 and 2.6 base Linux. Backup process writes a data stream of length 3.8 to 4.1GB, size is a multiple of 32k, growisofs writes the DVD, cdrecord writes the error message. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot
Re: Unidentified subject!
On Sat, Feb 18, 2006 at 08:56:12PM -0800, charles robison wrote: when i burn a cd with my burner an play it in cd player it goes in revirce. what is wrong? http://www.catb.org/~esr/faqs/smart-questions.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
David Willmore [EMAIL PROTECTED] wrote: In-Reply-To=[EMAIL PROTECTED]; from [EMAIL PROTECTED] on Tue, 14 Dec 2004 19: 46:32 +0100 Subject=Re: Re: DVD+R burning problem (other media okay) Date: Tue, 14 Dec 2004 21:12:55 -0500 From: David Willmore [EMAIL PROTECTED] I've heard that problem--which is why I mentioned that the write was not on one of those busses. So, to clarify, the errors are media errors, not errors in content. Can't read sector vs sector contains bad data. I did further testing. I installed cdrecord-ProDVD version Cdrecord-ProDVD-Clone 2.01b31 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling Unlocked features: ProDVD Clone Limited features: This copy of cdrecord is licensed for: private/research/educational_non-commercial_use With it, the media (labeled 4x) defaults to 8x burning. Media burnt that way with this program has a number of errors. When I hand set speed=4, I get no read errors on the burner drive, but it doesn't even read at 1x DVD speed. Another (older) 4x DVD reader reads errors on it. What writer do you use? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
Joerg Schilling wrote: Rob Bogus [EMAIL PROTECTED] wrote: Okay, I'll put them on a web site and send them off to a few vendors who have their own version anyway. That way you won't have to worry about losing it. It looks as if using a trailing dot will be more natural: Ex: /usr/local/src/. /opt/tmr/. /home myron/. instead of haveing to write graft-points: /usr/local/src=/usr/local/src /opt/tmr=/opt/tmr /home /home myron=/home myron since I doubt anyone writes that way, and backing up directories using the original names is useful. What you try to propose is nothing that could be accepted for the official mkisofs. The more you write on it the less benefits I see. /usr/local/src/. does not help at all as mkisofs could not know how much of the original path should be visible on the CD. If /usr/local/src/. is a shorthand for /usr/local/src=/usr/local/src with graft points, why would it be any easier to figure out just because it was a hell of a lot easier to use for multiple directories? I suspect what you mean is that it isn't your idea so you're against it. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
Rob Bogus [EMAIL PROTECTED] wrote: Okay, I'll put them on a web site and send them off to a few vendors who have their own version anyway. That way you won't have to worry about losing it. It looks as if using a trailing dot will be more natural: Ex: /usr/local/src/. /opt/tmr/. /home myron/. instead of haveing to write graft-points: /usr/local/src=/usr/local/src /opt/tmr=/opt/tmr /home /home myron=/home myron since I doubt anyone writes that way, and backing up directories using the original names is useful. What you try to propose is nothing that could be accepted for the official mkisofs. The more you write on it the less benefits I see. /usr/local/src/. does not help at all as mkisofs could not know how much of the original path should be visible on the CD. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
Joerg Schilling wrote: Rob Bogus [EMAIL PROTECTED] wrote: If that's what you want -graft-points var.www.1=/var/www/1 (you will need options for having multiple dots). And what I said works, at least here, -graft-points /var/www/1=/var/www/1 preserves everything. That's the whole point of addir backups. Joerg, would you accept a patch such that /var/www/1= with no trailing copy of the same string would be a shorthand for this behaviour? I am not sure if this would really make sense as you could easily write var.www.1=/var/www/1 instead of var.www.1= in special when you run scripts. The idea is not to solve the original poster's problem, but to avoid /var/www/1=/var/www/1 many times repeated when what is really wanted is to say /usr/local/src (or similar) and not have to use graft-points and say /usr/local/src=/usr/local/src. To say that the current behaviour is inconvenient when saving a large number of directories *in the original location*, since graft-points are needed. Also please note that I did not yet start with a new development cycle for cdrtools as I am currently working on Star's incremental restores. Sending patches now could easily get lost :-( Okay, I'll put them on a web site and send them off to a few vendors who have their own version anyway. That way you won't have to worry about losing it. It looks as if using a trailing dot will be more natural: Ex: /usr/local/src/. /opt/tmr/. /home myron/. instead of haveing to write graft-points: /usr/local/src=/usr/local/src /opt/tmr=/opt/tmr /home /home myron=/home myron since I doubt anyone writes that way, and backing up directories using the original names is useful. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
Rob Bogus [EMAIL PROTECTED] wrote: If that's what you want -graft-points var.www.1=/var/www/1 (you will need options for having multiple dots). And what I said works, at least here, -graft-points /var/www/1=/var/www/1 preserves everything. That's the whole point of addir backups. Joerg, would you accept a patch such that /var/www/1= with no trailing copy of the same string would be a shorthand for this behaviour? I am not sure if this would really make sense as you could easily write var.www.1=/var/www/1 instead of var.www.1= in special when you run scripts. Also please note that I did not yet start with a new development cycle for cdrtools as I am currently working on Star's incremental restores. Sending patches now could easily get lost :-( Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
_N4R3N_ wrote: hi all If i have a dir named /var/www/1.If i make an image using mkisofs with common options and write it on a cd I will see a copy of directory '1' on a cd . But i want to preserve the entire path such that the directory i m going to get should have the name 'var.www.1' Plz note that using graft points gives a diff result.How do i do this. Any ideas. Thanks in anticipation If that's what you want -graft-points var.www.1=/var/www/1 (you will need options for having multiple dots). And what I said works, at least here, -graft-points /var/www/1=/var/www/1 preserves everything. That's the whole point of addir backups. Joerg, would you accept a patch such that /var/www/1= with no trailing copy of the same string would be a shorthand for this behaviour? -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
_N4R3N_ wrote: hi I want to take data backup on to a cdrom.My problem is when i want to write two directories with the same name like 1./var/www 2./home/naren/www Sice both direcories have the same name(Since making an iso image with the two dirs combined is impossible ,since /home/naren/www automatically overwrites /var/www in an iso) Since mkisofs does not take in to matter the path to which the (I donno completely ) files r there but only takes in to accont the last name (i mean only the 'www' part) So finally i want to write it as 1. var.www 2.home.naren.www to make an iso image such that when it is burned on a cd gives two dirs var.www and home.naren.www I have to make some manipulation when trying to make them(1./var/www,2./home/naren/www) to iso image and then burn it on a cd How do i do this ??? Any suggestions See -graft-points and use the full name on the ISO image (like /home/me=/home/me) -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
From: Manuel Clos [EMAIL PROTECTED] I didn't know that it was unrelated stuff, I just looked into all the files searching for license statements. These sources that create e.g. the CRC tables are unneeded even in a souce distrbution. You only need it if you like to modify the code to make it fit to other applications that use different CRC polynoms... I don't know where this libedc_ecc come from, since I was unable to find a web page or tarball anywhere. It has been removed because cdrdao abuses it :-( Ok, let's fix it then. Well a few days did pass and nothing did happen. Why? Read the Copyright information inside cdrtools. Cdrtools use the package as intended. Ok, I see the problem now. Let me talk with Andreas. As I said before, I didn't know of this problem. It is interesting to see than Andreas did not even send a single mail. Is there no real interest to fix up the problem? Andreas definitely does know that libedc is _not_ GPL. He has the special permission to use libedc with cdrdao. The fact that he requested and received this special permission makes it clear that it _cannot_ be GPL. If it was GPLd code then this special permission is not needed A major problem with cdrdao is that the fact that cdrdao states that the whole project is GPLd makes authors of other SW believe that libedc is GPLd too. A senseful reaction from Andreas could be to immediately remove all copies that include the false claims and publish updated versions (e.g. cdrdao-1.1.5a, ...). In addition, it would be desirable that Andreas contacts all Authors of related SW that uses libedc and informs them to fix their licenses too. When will this hapen? Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am Jorg Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
From: Norbert Preining [EMAIL PROTECTED] On Don, 19 Sep 2002, Joerg Schilling wrote: It is interesting to see than Andreas did not even send a single mail. [...] Is there no real interest to fix up the problem? [...] SW that uses libedc and informs them to fix their licenses too. When will this hapen? Maybe you are the only one which is so crazy about this, and others just don't care, even the author? Hmm, think about this! Wrong: Heiko did write to Andreas about the problem and did not get an answer. It really looks like Andreas is in hope that waiting and doing nothing will cure the problem :-( If people who complain about the fact that companies abuse GPLd SW, then it is bad to see that GPL people at the same time abuse non-GPLd code. Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am Jorg Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
From: Bob [EMAIL PROTECTED] CDrtools 1.11a17 [root@herakleion zim]# uname -a Linux herakleion.purplefrog.com 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown [root@herakleion zim]# cat /etc/redhat-release Red Hat Linux release 7.2 (Enigma) I'm having poor luck re-writing CD-RWs. I almost always get errors when burning to CD-RW media. I can rarely record a full image. I have succeeded with fresh (un-recorded) CD-RWs, and once with a used CD-RW. Failures happen whether I am actively using the machine or not (I can go to bed with an image burning, and wake up to a failure message and a disk whose tail end is un-readable) I have burned two successful CD-Rs, and one coaster. Other non-critical problems: This is a Dell Inspiron 8100 laptop, and the stinking CD drive is on the same IDE controller as the hard drive. While blanking or fixating, the machine is unable to access the hard drive, and any program which attempts to access the hard drive will freeze until the blanking operation is complete. For a blank=all, I have time to go to lunch. While recording data, I can read mail, surf and do other stuff, though. I have not yet attempted a cdrecord from single-user mode (no daemons running). [root@herakleion zim]# ~thoth/src/cdrtools-1.11/cdrecord/OBJ/i686-linux-cc/cdrecord blank=fast dev=0,0,0 speed=0 -v zim2.iso Cdrecord 1.11a17 (i686-pc-linux-gnu) Copyright (C) 1995-2002 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '0,0,0' scsibus: 0 target: 0 lun: 0 Linux sg driver version: 3.1.19 Using libscg version 'schily-0.6' atapi: 1 Device type: Removable CD-ROM Version: 0 Response Format: 1 Vendor_info: 'MATSHITA' Identifikation : 'UJDA330 ' Revision : '1.50' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R Drive buf size : 1359872 = 1328 KB FIFO size : 4194304 = 4096 KB Track 01: data 588 MB Total size: 675 MB (66:57.73) = 301330 sectors Lout start: 676 MB (66:59/55) = 301330 sectors Current Secsize: 2048 ATIP info from disk: Indicated writing power: 5 Reference speed: 2 Is not unrestricted Is erasable ATIP start of lead in: -11745 (97:25/30) ATIP start of lead out: 359363 (79:53/38) speed low: 0 speed high: 4 power mult factor: 4 6 recommended erase/write power: 5 A2 values: 00 00 00 Disk type:Phase change Manuf. index: 40 Manufacturer: INFODISC Technology Co., Ltd. Blocks total: 1166730 Blocks current: 1166730 Blocks remaining: 865400 Starting to write CD/DVD at speed 2 in write mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Performing OPC... /home/thoth/src/cdrtools-1.11/cdrecord/OBJ/i686-linux-cc/cdrecord: OPC failed. Blanking PMA, TOC, pregap Blanking time: 90.729s Performing OPC... Starting new track at sector: 0 Track 01: 308 of 588 MB written (fifo 100%) 2.1x./home/thoth/src/cdrtools-1.11/cdrecord/OBJ/i686-linux-cc/cdrecord: Input/output error. write_g1: scsi sendcmd: no error CDB: 2A 00 00 02 69 75 00 00 1F 00 status: 0x2 (CHECK CONDITION) Sense Bytes: F0 00 03 00 02 89 DE 0C 00 00 00 00 0C 00 00 00 Sense Key: 0x3 Medium Error, Segment 0 Sense Code: 0x0C Qual 0x00 (write error) Fru 0x0 Sense flags: Blk 166366 (valid) cmd finished after 0.208s timeout 40s Try to clean the lens, stop smoking (if you do), use different media or let the drive be repaired. Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am Jorg Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix FOKUS at CeBIT Hall 11, A14 - BerliOS at CeBIT Hall 11 D11 (Future Market) Meet me at CeBIT in Hall 11 D11 on the BerliOS booth - www.berlios.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
Hi, On Mon, Jun 18, 2001 at 06:43:36PM +0200, Alexander Skwar wrote: So sprach [EMAIL PROTECTED] am Mon, Jun 18, 2001 at 06:29:47PM +0200: Well the price of a Solaris installation is _exactly_ the same a the price for a Linux installation! Ah, okay. This also includes the numerous Solaris boards and huge pile of software available for Solaris? Where can I find, let's say, KDE II or Evolution 1.0.3 for Solaris? Does it compile just as easily there as it does on Linux? FYI, from the SUN website: - Sun is a charter member of the GNOME Foundation and an active member of the GNOME community. Sun is committed to delivering a high-quality GNOME user environment for the Solaris Operating Environment, and to providing dedicated resources for the ongoing development and enhancement of GNOME. Availability Sun will offer GNOME 2.0 for the Solaris Operating Environment. Development of the 2.0 release is still in the early stages. The following is a preliminary release schedule: * Q1 CY 2001: Public early access * Q2 CY 2001: Beta early access * Q3 CY 2001: General availability - AFAIK you can already download Gnome 1.4 at the moment. So there may may be no KDE, but there's Gnome and it will be the standard Solaris dektop in the future. For further information, look at : http://www.sun.com/software/gnome/siteindex.html Also you can download Solaris 8 free of charge and at least parts of it are open source now. Cheers, Dirk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
From: [EMAIL PROTECTED] (Bill Davidsen) [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] (Bill Davidsen) Mike A. Harris [EMAIL PROTECTED] wrote: /usr/bin/which is an ELF executable on Red Hat Linux, but I agree that it definitely is not an application that can be expected to be portable. One of the reasons bash added 'type' as a builtin. Type is a shell builtin at least since 1982. I didn't know bash had been around that long, but why is the date relevant to the choice to include the feature when designing bash? This is funny you write a statement that is close to 'bash invented type' and dont understand when I tell you that type is a stone age command. Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am Jorg Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
[EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] (Bill Davidsen) [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] (Bill Davidsen) Mike A. Harris [EMAIL PROTECTED] wrote: /usr/bin/which is an ELF executable on Red Hat Linux, but I agree that it definitely is not an application that can be expected to be portable. One of the reasons bash added 'type' as a builtin. Type is a shell builtin at least since 1982. I didn't know bash had been around that long, but why is the date relevant to the choice to include the feature when designing bash? This is funny you write a statement that is close to 'bash invented type' and dont understand when I tell you that type is a stone age command. I still don't see why the date matters. When the design was done, some existing features like 'type' were included, some were left out, and some were slightly changed or enhanced. I don't see anywhere that I made any statement at all about invention, only that the feature was chosen for inclusion. We were talking about shells and 'which,' not sure what you're talking about. For some reason you seem to think that the date is very important, but I think it's also wrong, bash isn't that old. -- -bill davidsen ([EMAIL PROTECTED]) The secret to procrastination is to put things off until the last possible moment - but no longer -me [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] (Bill Davidsen) [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] (Bill Davidsen) Mike A. Harris [EMAIL PROTECTED] wrote: /usr/bin/which is an ELF executable on Red Hat Linux, but I agree that it definitely is not an application that can be expected to be portable. One of the reasons bash added 'type' as a builtin. Type is a shell builtin at least since 1982. I didn't know bash had been around that long, but why is the date relevant to the choice to include the feature when designing bash? This is funny you write a statement that is close to 'bash invented type' and dont understand when I tell you that type is a stone age command. I still don't see why the date matters. When the design was done, some existing features like 'type' were included, some were left out, and some were slightly changed or enhanced. I don't see anywhere that I made any statement at all about invention, only that the feature was chosen for inclusion. We were talking about shells and 'which,' not sure what you're talking about. For some reason you seem to think that the date is very important, but I think it's also wrong, bash isn't that old. -- -bill davidsen ([EMAIL PROTECTED]) The secret to procrastination is to put things off until the last possible moment - but no longer -me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
From [EMAIL PROTECTED] Mon Jun 18 18:43:44 2001 So sprach [EMAIL PROTECTED] am Mon, Jun 18, 2001 at 06:29:47PM +0200: Well the price of a Solaris installation is _exactly_ the same a the price for a Linux installation! Ah, okay. This also includes the numerous Solaris boards and huge pile of software available for Solaris? Where can I find, let's say, KDE II or Evolution 1.0.3 for Solaris? Does it compile just as easily there as it does on Linux? We are going in circles, but I hope it helps: It a specific software does not compile on Solaris, complain at the Authors. They did a bad job in such a case... Note: Free Software the way you know it has been born on SunOS Solaris. So any software that exists before 1995 should be more or less clean and build on Solaris without problems. Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am Jorg Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
On Fri, 23 Feb 2001 [EMAIL PROTECTED] wrote: From [EMAIL PROTECTED] Fri Feb 23 12:38:26 2001 I never had problems to compile with GNU make until I switched to smake. Sorry, this should be: I never had problems to compile with GNU make _before_ I switched to smake. Or if you want to go all out: _I've_ never had problems _compiling_ with GNU make before _switching_ to smake. ;o) (Sorry.. couldn't resist.. too tempting..) ;o) -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2001, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports on it, you know they are just evil lies. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
In [EMAIL PROTECTED], Joerg Schilling [EMAIL PROTECTED] offers the opinion: From [EMAIL PROTECTED] Tue Oct 17 05:49:19 2000 Back in the days of cdwrite there used to be a program called 'isosize' which is used something like this to read iso9660 data CDs: $ isosize /dev/sr0 670564352 Isosize is outdated: - The output is useless for cdrecord because it lists bytes. - It is not needed anymore since 97/03/02 (read cdrecord manpage!) - In addition isoinfo -d gives you the information in a useful way (since January 2000). When I'm looking for a size to use in another program, I'm afraid that I don't consider 14 lines of data in "Item: value" exactly a "useful way." The isosize gave me the single number for size, which I could maniputate as needed. Yes I can use grep and sed, or perl, or awk, but I would find the size in some unit I actually use vastly more convenient. viz. old: bytes=$(isosize /dev/sr0 ) new: bytes=$(expr 2048 \* $(isoinfo | grep 'Volume size is:' | sed 's/.*: //')) So I guess "useful way" is in the eye of the beholder, and means "useful to the author." -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
