Processed: Re: Bug#468850: simple-cdd: To add mkisofs dependency

2008-03-05 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]: > reassign 468850 debian-cd Bug#468850: simple-cdd: To add mkisofs dependency Bug reassigned from package `simple-cdd' to `debian-cd'. > retitle 468850 should use by default whatever ISO generator is available Bug#468850: simple-cdd

Re: DOS compatible again? 8+3 names broken due to mkisofs option

2004-10-26 Thread Steve McIntyre
On Thu, Oct 21, 2004 at 11:51:01PM +0200, Santiago Garcia Mantinan wrote: > >But I definitely think it is of no sense on i386, here it doesn't provide >anything (we already have long names through joliet) and it breaks >compatibility with the old DOS based systems. So, I'm for removing this -l >opt

DOS compatible again? 8+3 names broken due to mkisofs option

2004-10-21 Thread Santiago Garcia Mantinan
Hi! While trying to make our cds compatible with DOS again we have identified several problems, the last one is that we are generating duplicate 8+3 names, which means that some files on the cds aren't accesible to DOS. The problem with this is that we are using the -l option in our mk

Bug#85672: mkisofs: symlink tree support for mkisofs

2001-02-11 Thread Chris Lawrence
Package: mkisofs Version: 3:1.9-1 Severity: important Tags: patch (CC'd to debian-cd this report is probably of interest to people there.) The following patch should cleanly incorporate the symlink tree support into mkisofs, provide the mkhybrid symlink and man page, and make the pa

RE: mkisofs, cdrecord, 74min vs 80min CDROM media

2001-02-07 Thread J.A. Bezemer
On Tue, 6 Feb 2001, Allison, Jason A. wrote: > > AFAIK mkisofs sorts the contents of each directory strictly > > alphabetically, > > diving into subdirectories according to their place in their parent, so > > first > > /a/a/a, then /a/a/b, /a/b, /a/c/a etc. up t

RE: mkisofs, cdrecord, 74min vs 80min CDROM media

2001-02-06 Thread Allison, Jason A.
> AFAIK mkisofs sorts the contents of each directory strictly > alphabetically, > diving into subdirectories according to their place in their parent, so > first > /a/a/a, then /a/a/b, /a/b, /a/c/a etc. up to /z/z/z. > > (And indeed, the farther from the center (i.e. at

RE: mkisofs, cdrecord, 74min vs 80min CDROM media

2001-02-06 Thread J.A. Bezemer
follow the track very well. This will produce a "track following error" during writing, and cdrecord will abort. This occurs "only" if the drive has been intensively used for reading (instead of writing). > Can you/anyone give some insight into how mkisofs performs the

RE: mkisofs, cdrecord, 74min vs 80min CDROM media

2001-02-06 Thread Allison, Jason A.
e)? What are the symptoms of a bad drive? I am getting kernal messages, "CAM SCSI" error messages which I beleive are "timeouts" to read the device. Though it will eventually read the data fine, are there other messages I may expect? Can you/anyone give some insight into how

Re: mkisofs, cdrecord, 74min vs 80min CDROM media

2001-02-06 Thread J.A. Bezemer
drive wears off before the 1-year warranty expires and you'll get a free replacement ;-) > mkisofs having problems with such a large > file. I am going to test expanding that tar file out and recording then. > Though 2 > files log

Re: mkisofs, cdrecord, 74min vs 80min CDROM media

2001-02-02 Thread Tal Danzig
nting to type it all again. > > > What I am using: > Alpha'a running Digital UNIX 4.0d > SCSI Yamaha CD-RW >

mkisofs, cdrecord, 74min vs 80min CDROM media

2001-02-02 Thread Allison, Jason A.
CD-RW cdrecord 1.9 w/ packaged mkisofs I updated from cdrecord 1.6.1 to 1.9 hoping to solve this problem, but to no luck, here I am. I am burning iso9660CD CDs. Here are my com

Re: mkisofs

2001-01-06 Thread Peter Horton
On Sat, Jan 06, 2001 at 09:11:13AM +0100, Robert Waldner wrote: > >> The ISO image read of the CD is probably a sector or two > >> too long. If you know the correct size then you can just do > > I would think that the image created with dd is a few bytes (less than > a sector) too small, because

Re: mkisofs

2001-01-06 Thread Peter Horton
Well, if you're lucky it'll only be a few sectors too long. Use the length of the image you've got minus 2K. Test and repeat. You might want to look at the image with a hex editor for clues. P. On Fri, Jan 05, 2001 at 07:05:33PM -0500, Debian User wrote: > What if you don't know the size, say, y

Re: mkisofs

2001-01-06 Thread J.A. Bezemer
ast 2352-byte block (which is required by standards). -pad for _data_ tracks always adds 30kB of 0's to make it compatible with buggy early 2.0 (IIRC) Linuxes and some other *UXes. Data tracks are always 2048-multiples, and if not then that's a serious bug in mkisofs (or equiv). Regards,

Re: mkisofs

2001-01-06 Thread J.A. Bezemer
On Sat, 6 Jan 2001, Tibor D. wrote: > Debian User wrote: > > > What if you don't know the size, say, you are trying to burn someone's > > cd to have a copy for yourself. > > Peter Horton wrote: > > > try dd if=. count=`isosize' > isosize is in the xcdroast and the cdwrite package. dd if=/

Re: mkisofs

2001-01-06 Thread Tibor D.
Debian User wrote: > What if you don't know the size, say, you are trying to burn someone's > cd to have a copy for yourself. > Peter Horton wrote: > try dd if=. count=`isosize' isosize is in the xcdroast and the cdwrite package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a su

Re: mkisofs

2001-01-05 Thread Robert Waldner
>> The ISO image read of the CD is probably a sector or two >> too long. If you know the correct size then you can just do I would think that the image created with dd is a few bytes (less than a sector) too small, because dd reads until it runs out of useful data, but the cd consists of 2k-sec

Re: mkisofs

2001-01-05 Thread Debian User
What if you don't know the size, say, you are trying to burn someone's cd to have a copy for yourself. Peter Horton wrote: > On Fri, Jan 05, 2001 at 11:49:10AM -0500, Antonio Rodriguez wrote: > > Hi Steve, hi all. Tried > > dd if=/dev/scd0 of=d3.iso > > with my deb official cd 3 (potato rev2). >

Re: mkisofs

2001-01-05 Thread Peter Horton
On Fri, Jan 05, 2001 at 11:49:10AM -0500, Antonio Rodriguez wrote: > Hi Steve, hi all. Tried > dd if=/dev/scd0 of=d3.iso > with my deb official cd 3 (potato rev2). > md5sum d3.iso gives not the supposed value. > When I do it from xcdroast I get the right md5sum. > Where is the problem? Are you su

Re: mkisofs

2001-01-05 Thread Antonio Rodriguez
Hi Steve, hi all. Tried dd if=/dev/scd0 of=d3.iso with my deb official cd 3 (potato rev2). md5sum d3.iso gives not the supposed value. When I do it from xcdroast I get the right md5sum. Where is the problem? Are you sure that there no options left out somewhere? Thanks, AR. Steve McIntyre wrote:

Re: mkisofs

2001-01-03 Thread csj
ck CD (correct me if I'm wrong). I'm been trying out "readcd", available in the the mkisofs/cdrecord package. So far I've been able to copy only the first and last track off a multitrack CD. Does anybody have any idea how to use readcd or some other tool to do a multitra

Re: mkisofs

2001-01-02 Thread Goswin Brederlow
> " " == Antonio Rodriguez <[EMAIL PROTECTED]> writes: > Can somebody indicate what excatly must the command line be to > copy the contents of a cd to some file and store it as iso > image? I tried different options to do it, but the md5sum > didn't match afterwards. Some

Re: mkisofs

2001-01-02 Thread Steve McIntyre
On Tue, Jan 02, 2001 at 02:49:48PM +, Antonio Rodriguez wrote: > >Can somebody indicate what excatly must the command line be to copy the >contents of a cd to some file and store it as iso image? >I tried different options to do it, but the md5sum didn't match >afterwards. Something like the

mkisofs

2001-01-02 Thread Antonio Rodriguez
Can somebody indicate what excatly must the command line be to copy the contents of a cd to some file and store it as iso image? I tried different options to do it, but the md5sum didn't match afterwards. Something like the internal commandfor xcdroast perhaps, since it has worked in the same cas