Re: cdwrite@other.debian.org
Hi, My purpose using RockRidge is retaining oringal ownership and permission of data to solve following problem; I burnt /home/ of a FC3 box on CDs. /home/ was on its own partition. Then running LFS LiveCD I copied the CDs on a partition of a new HD [...] Later I discovered all data after transferred from the CDs onto the partitions became read only and permission changed from User to Root. Now I need to reinstate their original state, i.e. Write/Read, User, etc. Not knowing the particular capabilities of your mkisofs version and of your ISO filesystem driver, i would generally state that a plain ISO tree is not the best candidate for exact 1:1 data backup or transport. (It is my favorite for user data backup, though, if ownership and permissions are trivial.) mkzftree ... that's new to me ... it seems to add another level of complexity. I would only employ such a thing if the other open issues are settled. With my own backup tool i advise to use afio or star format if ownership or permissions are essential or other file types than plain, dir or softlink are to be backuped. mkisofs -R does record more file attributes and therefore might be usable with other than just the above filetypes but i would not trust it to record really everything. Especially since you have to cope with the possible peculiarities of the ISO filesystem driver when reading the data. My favorites for recording everything (but not a whole partition) are currently : find | afio -o (or afio -oZ , rather than afio -o | gzip) resp. star -c -xdev -acl -link-dirs -dump Maybe Joerg can propose an even better star command for your purpose. One may compress the output, one may encrypt it, and one may pipe it into cdrecord | cdrecord ... - or growisofs | growisofs ... -Z /dev/dvd=/dev/fd/0 like one would have done with an ISO image. To be read directly from unmounted media like from a tape device afio -tv /dev/cdrom resp. star tvzf /dev/cdrom You may do this with any trustworthy archiver, of course. Not only with afio or star. You may also direct the archiver output into a hard disk file and use your usual burn program to put that file on media. Then you would have to unpack it from *mounted* media by something like afio -tv /mnt/my_archive_file.afioz And of course, the content info options t have to be replaced by the unpack options of the archivers i resp. x. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: *** Bogofilter Spamverdacht *** Re: Problems with dvd+rw-tools 6 and Pioneer drive
Sorry for capturing this thread :-), I know that my drive is a LG and not a Pioneer, of course. But I think the problem with the speed option of growisofs 6.0 is vendor independent, my guess is that it should happen with all drives with minimum writing speed of 2. I hope that I'm not wrong about that, I bet it would make it more difficult to fix if it *is* an vendor specific problem with LG. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with dvd+rw-tools 6 and Pioneer drive
Sorry for capturing this thread :-), I know that my drive is a LG and not a Pioneer, of course (and sorry for double posting, I didn't have look at the subject before posting). But I think the problem with the speed option of growisofs 6.0 is vendor independent, my guess is that it should happen with all drives with minimum writing speed of 2. I hope that I'm not wrong about that, I bet it would make it more difficult to fix if it *is* an vendor specific problem with LG. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools cdrecord/cdrecord.c
Joerg Schilling wrote: Steve McIntyre [EMAIL PROTECTED] wrote: The full set of Debian patches against cdrecord are: 02_cdrecord_default_conf.dpatch: Set up reasonable default values in the cdrecord config It is unreasonable to deviate from a standard OS independen default. --- rejected Do you not see you look like a fool on this? You put in Linux dependent stuff which is totally WRONG (see below) but you say configuration which SHOULD be how the program learns about the environment must not contain useful information about the execution environment. 06_dautipps.dpatch: Little patch to extend error information This patch causes incorrect output --- rejected You spelled useful wrong, s/incorrect/useful/ 17_argv0_beautify.dpatch: Remove the Debian specific suffix from the executable filename A patch caused by the fact that Debian is missing fundamental knowledge on version incompatibility and is uneducatable! You cannot expect a cdrecord compiled on Linux version N to run on Linux version N - X You can if the person who designed the build system is competent. 18_donotopen_hda.dpatch: dev=ATA:1,0,0 uselessly opens /dev/hda, breaking non-root access. See #228215 Trying to patch a problem caused by incorrecty usage (the man page clearly states which provilleges you need to run cdrecord). --- rejected So the program needs extra permissions because you aren't competent enough to avoid doing something not needed? 21_makefile_fix_for_kernel.dpatch: Fix problems with kernel include doing wrong things. Unneded at all at least if the Linux kernel include files are non-buggy. In addition, the autoconf utility already tests for known Linux kernel bugs. --- rejected Whoever wrote the autoconf clearly doesn't understand how to program. The process looks for include files which may not exist and may not be correct. User programs should be using the released headers, and it is the job of the user to get them. 22_linux_rawio_capability.dpatch: Add linux specific rawio capability allocation to work with kernels 2.6.8 Needed only because fine grained privileges are not yet ready for general use. It is a general rule to wait until a newe feature has grown up from the experimental state. --- rejected Again, this is the correct way to get capabilities, programmers who are living in the past don't know about it. 23_o_excl.dpatch: Open devices with O_EXCL to stop other programs from interrupting writes general rule: Fix the other programs that are broken --- rejected That's stupid, you can't fix or even IDENTIFY all programs ever written to prevent problems. Shows a total understanding of how the real world works. 27_scsi_buffer_size.dpatch: If we can't get a buffer as big as we would like, shrink the desired size until it works. Bug #330371 This is only a workaround for a bug introduced into the Linux kernel by Jens Axboe (better fix the kernel). --- rejected Another case of not having the skill to adapt the application to fixes in the O/S. 35_ultra_speed_media.dpatch: Simple bug fix for ultra high speed RW media detection This problem has been fixed in cdrecord more than a month before Debian --- rejected So you see: not a single patch is senseful. Jörg Unfortunately it's clear that you learned how to interface with the kernel a decade ago and are not longer able to keep up with the technology. Symtpoms of alzheimer's include inability to adapt to change and being argumentative. Time to find a version of the tools which are maintained to work as things are, rather than as someone would like them to be. Thanks for the work you did in your prime. -- 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: dvd+rw-tools update [6.0, DVD-R DL]
Joerg Schilling wrote: Bill Davidsen [EMAIL PROTECTED] wrote: O_DIRECT is no standard and it seems that it is just a reimplementation of the very old DG/UX idea of O_DG_UNBUFFERED. The idea of doing unbuffered i/o is hardly that young, I believe you will trace it back to MULTICS and GECOS in the late 60's. IIRC that was done when the buffer was alligned and size to allow it, not by explicit user request. Having the user set a flag to request that behaviour came later, and I'm unsure of the portability, since there is a POSIX call to get the sized and aligned buffer allocated. At least for discussion portability is not the issue regarding performance on a single o/s type. Without a proof for equivalence, I would asume that what you mention here if unbuffered I/O at device level and not at file level. The fact that Linux Linux failed to implement effifient unbufered I/O at device level for a long time (and not does in a way that does not look UNIX like) is just a cause if the implementation in Linux. Note that what you get with this feature is less than what you get from a decent VM buffer subsystem. It's hard to imagine how an i/o to a system buffer, followed by a copy to a possibly misaligned user bufffer is going to be faster that i/o to a user buffer which is sized and aligned to allow transfer of an integer number of sectors. I hear what you say, but looking at the physics I have to think the measurement is wrong or the direct i/o is slowed by delays in the o/s. Unaligned bufferes do not have much effect on the I/O speed except when you use hardware (DMA) to do copies. Even then, a utility like star that offers buffers aligned at a 512 byte grid is sufficient. Most speed improvements result from avoiding I/O and this is something that works with deceltly buffered I/O. For a real compare you need to test Solaris vs. Linux on the same hardware (I did not say or mean identical hardware, but SAME hardware), and test O_DIRECT vs. normal system buffered. I did not test O_DIRECT because I believe it is not worth testing after the experiences with DG/UX, but star is notiable faster if you boot the same hardware with Solaris instead of Linux. You can fix the limitations of star by using O_DIRECT... -- 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: cdrtools cdrecord/cdrecord.c
Joerg Schilling wrote: Ville Syrjälä [EMAIL PROTECTED] wrote: On Mon, Jan 23, 2006 at 03:41:16PM +0100, Joerg Schilling wrote: Geoffrey [EMAIL PROTECTED] wrote: I am not against Linux, however I don't like the way the Linux kernel developers personally attack people who tell them where they make mistakes. Let me make an example: if you take Linus Torvalds statements on Linux kernel include files for serious, then it is _forbidden_ to test kernel interfaces. Well, first note that glibc does not even know about most kernel interfaces, the include files that come with glibc are much older than the linux kernel. If I add a new interface to the linux kernel today or if I enhance an old one, I cannot test it in case I am only allowed to use the include files from glibc. Whose preventing you from testing it? For your testing you can do anything you like. However when distributing the program it would help the distro people if you just used the standard /usr/include path. You did not understand it: - If you need to break a rule on a regular base it is nonsense. - Linux decided to _need_ /usr/src/linux/unclude in the search PATH. It was needed for Linux-2.2 or earlier and such a decision cannot ever be changed later. Hogwash. There is a set of includes for each kernel, or subset of kernels sharing headers, and you use that and make the user specify the location. It's easier than making the user patch your broken build tools. There is no directory /usr/src/linux on most systems, it's only used for kernel development. You are counting on something which has not been commonly present for a decade. -- 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: cdrtools cdrecord/cdrecord.c
Joerg Schilling wrote: Matthias Andree [EMAIL PROTECTED] wrote: Joerg Schilling schrieb am 2006-01-22: First: this is not a bug inside cdrecord that needs to be fixed but a recently introduced bug in Linux that needs a workaround. I don't care how you call it. It's a problem between cdrecord and Linux that needs to be fixed. Since you insisted that setuid would work in Linux (which it doesn't), I'm showing you what works for me ATM. I'm not claiming it's appplicable as is, I wanted to hear how your review is going. You stated that it does not work on Linux-2.6.8.1 which is not true. Please understand that I am not willing to waste my time with constanly trying out new Linux version as long as the Linux Folks is not willing to to stop introducing new problems for CD/DVD writing. Fortunately there are people who do, which is why there are patches to fix the limitations of the old interface you release. You are saying the world should stop changing because I don't have time to keep up. For this reason, I cannot try out problems with Linux versions ewer than 2.6.8.1 unless people give access to machines where newer versions are installed. Did you ever wonder why no one provides access? -- 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: cdrtools cdrecord/cdrecord.c
Joerg Schilling wrote: Bill Davidsen [EMAIL PROTECTED] wrote: Even for Open Source, there is an Author or a group of authors. The version that comes from the Copyrightholder is the official one. In this case there is no such official one, the official growisofs doesn't do CD, the official cdrecord doesn't do DVD. So neither of The official cdrecord writes DVDs since early March 1998. Where do we get source for this official version? The one I find on your site doesn't seem to do DVD, it just prints a bunch of advertizing for some silly closed source thing -- 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: cdrtools cdrecord/cdrecord.c
On Tue, Jan 24, 2006 at 07:47:00AM -0500, Bill Davidsen wrote: Joerg Schilling wrote: For this reason, I cannot try out problems with Linux versions ewer than 2.6.8.1 unless people give access to machines where newer versions are installed. Did you ever wonder why no one provides access? ... because none of the REST of us have time to play chase the latest unstable Linux 2.6 kernel games either. Well, except for the Gentoo users -- obviously *they* have time, since that seems to be what they devote their entire lives to. HP-UX imadev B.10.20 A 9000/785 2008xx two-user license OpenBSD pegasus 3.8 GENERIC#0 i386 Linux griffon 2.4.32 #7 Mon Dec 5 19:58:55 EST 2005 i686 GNU/Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools cdrecord/cdrecord.c
On Tue, 24 Jan 2006, Bill Davidsen wrote: Fortunately there are people who do, which is why there are patches to fix the limitations of the old interface you release. You are saying the world should stop changing because I don't have time to keep up. This argument is invalid. It expects everyone using Linux has the time and is ready to deal with a random changes any day, and has ressources to follow every random change. In the reverse direction, it is pretty clear that the kernel development model ignores stability, reliability, responsibility - only the kind souls of the 2.6.X.Y project holding up the tiny bit of it that they can get a hold of. That's innovation at all costs (where cost includes quality) because no-one has to answer for anything he goofs up. I know that most kernel hackers aren't idiots, yet having to support one's changes for more than a few -rc* would probably make people think twice before committing incompatible changes. -- Matthias Andree -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: cdrtools cdrecord/cdrecord.c
Volker Kuhlmann [EMAIL PROTECTED] wrote: Could you give an example where cdrecord dumps hexadecimal rubbish to signal that everything is OK? I know it dumps a lot in -vv mode, but that's what -vv is designed for... Device seems to be: Generic mmc2 DVD-R/DVD-RW. Current: 0x0008 Are you talking about this? Device seems to be: Generic mmc2 DVD-R/DVD-RW. Current: none Profile: DVD+R Profile: DVD+RW Profile: DVD-RW sequential overwrite Profile: DVD-RW restricted overwrite Profile: DVD-R sequential recording Profile: DVD-ROM Profile: CD-RW Profile: CD-R Profile: CD-ROM 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: About RockRidge
Stephen Liu [EMAIL PROTECTED] wrote: My purpose using RockRidge is retaining oringal ownership and permission of data to solve following problem; I burnt /home/ of a FC3 box on CDs. /home/ was on its own partition. Then running LFS LiveCD I copied the CDs on a partition of a new HD which has 6 partitions. I'm prepared to build LFS--BLFS on the new HD applying LFS LiveCD as host. Later I discovered all data after transferred from the CDs onto the partitions became read only and permission changed from User to Root. Now I need to reinstate their Try man mkisofs to learn how to correctly use RR. 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: dvd+rw-tools update [6.0, DVD-R DL]
Bill Davidsen [EMAIL PROTECTED] wrote: From reading your last mail, it seems that you seem to be a novice. Let me give you the advise that it helps a lot to shorten quotings in order to get accepted by knowledgeable people. I did not test O_DIRECT because I believe it is not worth testing after the experiences with DG/UX, but star is notiable faster if you boot the same hardware with Solaris instead of Linux. You can fix the limitations of star by using O_DIRECT... ??? This sounds a bit confused. Are you able to describe your concern? 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: cdrtools cdrecord/cdrecord.c
Bill Davidsen [EMAIL PROTECTED] wrote: The full set of Debian patches against cdrecord are: 02_cdrecord_default_conf.dpatch: Set up reasonable default values in the cdrecord config It is unreasonable to deviate from a standard OS independen default. --- rejected Do you not see you look like a fool on this? You put in Linux dependent stuff which is totally WRONG (see below) but you say configuration which SHOULD be how the program learns about the environment must not contain useful information about the execution environment. Calm down and try to get informed about what we are talking. 06_dautipps.dpatch: Little patch to extend error information This patch causes incorrect output --- rejected You spelled useful wrong, s/incorrect/useful/ Try to have a look at the patch in question and try to understand the result before answering. 17_argv0_beautify.dpatch: Remove the Debian specific suffix from the executable filename A patch caused by the fact that Debian is missing fundamental knowledge on version incompatibility and is uneducatable! You cannot expect a cdrecord compiled on Linux version N to run on Linux version N - X You can if the person who designed the build system is competent. If you are competent, please try to help me to educate the Debian people to set up a correct build system. Meanwhile you seem to agree that this patch is nonsense! 18_donotopen_hda.dpatch: dev=ATA:1,0,0 uselessly opens /dev/hda, breaking non-root access. See #228215 Trying to patch a problem caused by incorrecty usage (the man page clearly states which provilleges you need to run cdrecord). --- rejected So the program needs extra permissions because you aren't competent enough to avoid doing something not needed? Well I am competent enough but I am not sure if you are... Maybe it helps if you try to first understand the duty of a platform and device independent SCSI generic transport library. [unrelated whening removed] ... 22_linux_rawio_capability.dpatch: Add linux specific rawio capability allocation to work with kernels 2.6.8 Needed only because fine grained privileges are not yet ready for general use. It is a general rule to wait until a newe feature has grown up from the experimental state. --- rejected Again, this is the correct way to get capabilities, programmers who are living in the past don't know about it. Try to inform yourself about how fine grained privileges work and how to run programs like cdrecord root-less. You are correct, it seems that you are living in the past and still need to understand some basics in fine grained privileges. 23_o_excl.dpatch: Open devices with O_EXCL to stop other programs from interrupting writes general rule: Fix the other programs that are broken --- rejected That's stupid, you can't fix or even IDENTIFY all programs ever written to prevent problems. Shows a total understanding of how the real world works. Well, it is stupid to try to patch cdrecord in a way that causes cdrecord to fail in documented use cases. It seems that you did not yet understand how to reliably maintain larger systems. Another case of not having the skill to adapt the application to fixes in the O/S. Try to understand documented interfaces and try to understand that an OS that partially implements interfaces not to follow the documented way needs to be called broken. Unfortunately it's clear that you learned how to interface with the kernel a decade ago and are not longer able to keep up with the technology. Symtpoms of alzheimer's include inability to adapt to change and being argumentative. Time to find a version of the tools which are maintained to work as things are, rather than as someone would like them to be. Thanks for the work you did in your prime. Well, it is obviously you who did not learn during the last years. 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: About RockRidge
Hi Joerg, Tks for your advice. - snip - My purpose using RockRidge is retaining oringal ownership and permission of data .. - snip - Try man mkisofs to learn how to correctly use RR. I went through man mkisofs(8) and came to following conclusion. If the original mode of directories and files are; directory=0664 file=0664 owner and group=satimis:satimis To preserve the original state after burning, the command line will be; # mkisofs -o cd.iso -r -uid satimis -gid satimis -dir-mode 0664 -file-mode 0664 -new-dir-mode 0664 /path/to/data If I'm wrong please correct me. I'm not clear of -z option, what does it mean transparently compressed file and the resulting disks are only transparently readable'? TIA B.R. SL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
failed with SK=5h/ASC=30h/ACQ=06h]: Invalid argument
Greetings; Just can't seem to get this Dell XPS Gen2 Notebook to burn a Memorex DVD +RW 8X no matter what I try, but now I'm out of tricks without these latest errors coming up with any of my last searches, in case it still looks familiar to anyone: Thanks, localhost# growisofs -dvd-compat -Z /dev/cd0 -R -graft-points -path-list /root/scripts/path-list 0.32% done, estimate finish Tue Jan 24 13:50:43 2006 0.64% done, estimate finish Tue Jan 24 13:53:19 2006 0.96% done, estimate finish Tue Jan 24 13:54:12 2006 /dev/pass0: pre-formatting blank DVD+RW... /dev/pass0: Current Write Speed is 2.5x1385KBps. :-[ [EMAIL PROTECTED] failed with SK=5h/ASC=30h/ACQ=10h]: Invalid argument :-( media is not formatted or unsupported. :-( write failed: Invalid argument localhost# dvd+rw-format /dev/cd0 * DVD±RW/-RAM format utility by [EMAIL PROTECTED], version 6.0. * 4.7GB DVD+RW media detected. * formatting 0.0|:-[ STOP DE-ICING failed with SK=5h/ASC=30h/ACQ=06h]: Invalid argument localhost# dvd+rw-mediainfo /dev/cd0 INQUIRY:[SONY][DVD+-RW DW-D56A ][PDS3] GET [CURRENT] CONFIGURATION: Mounted Media: 1Ah, DVD+RW Media ID: RITEK/008 Current Write Speed: 2.4x1385=3324KB/s Write Speed #0:2.4x1385=3324KB/s GET [CURRENT] PERFORMANCE: Write Performance: 2.4x1385=3324KB/[EMAIL PROTECTED] - 0] Speed Descriptor#0:00/0 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s READ DVD STRUCTURE[#0h]: Media Book Type: 93h, DVD+RW book [revision 3] Legacy lead-out at:2295104*2KB=4700372992 READ DISC INFORMATION: Disc status: blank Number of Sessions:1 State of Last Session: empty Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: blank Track Start Address: 0*2KB Free Blocks: 2295104*2KB Track Size:2295104*2KB READ CAPACITY: 0*2048=0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
