cdrecord web site disappeared (was: Re: cdrecord doesn't appear to support high speed media (4x-12x))
On Sun, Jun 05, 2005 at 10:54:27PM -0400, Steven Friedrich wrote: On Sunday 05 June 2005 10:40 pm, Rob Bogus wrote: Steven Friedrich wrote: Under FreeBSD ports, the description for cdrecord gives this web site: http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html but it's no longer there. I would like to hear more about that... I don't know what you mean. Did you try to go to this web site? Was it there? Indeed it was there (for as long as i can remember). It is no longer there. Apparently, fokus.gmd.de is now fokus.fraunhofer.de and they have reorganized their web site and some stuff is now gone. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux kernel 2.6.x Raw device support
On Sat, May 21, 2005 at 08:16:46AM -0400, James Finnall wrote: On Saturday 21 May 2005 05:52, [EMAIL PROTECTED] wrote: Just for curiosity: when did this raw device thingee start to work ? Is it a spinoff from udf-tools ? How official did it become inbetween ? I'm still using kernel 2.4 and obviously missed some interesting dead end developments. There is mentioned an open(2) option O_DIRECT and a command raw(8) in my system's man pages. Thoughtful YaST did not install any (according to raw -qa). The man page for the raw command gives the author, Stephen Tweedie at Redhat, the credit for the raw command program and at the bottom of the man page it is dated August 1999 on my system. The 2.6.10 kernel sources for the raw device driver sources do not offer any history within the contents. So I do not know when the implementation of the device structure itself was first started or where. I did see a statement that included the phrase genuine UNIX and that would imply to me that this is not a Linux specific feature however. In the 2.6 series kernel it is an optional item. I could not locate an option in the 2.4 series kernel to disable the feature so I assume it is mandatory, but the raw.c source code is there for char device support. Support for raw block devices is indeed not Linux-specific. IIRC, it was an answer to commercial database vendors, who insisted at the time that without raw devices, Linux was not suitable as an OS for database servers (as opposed to commercial Unices, who have raw block devices). It definitely have nothing to do (in terms of its origins) with UDF support. Again IIRC, this was a very, very long time ago. I don't remember how long ago, unfortunately. I find it a bit hard to believe that raw devices would be dropped from the kernel. However, raw -qa not listing anything installed would be normal. IIRC (again), Linux would (by design) have no raw devices by default; rather, each raw device would have to be manually configured by the user (to avoid wasting device numbers for unused raw devices). This is different from raw devices in other Unices (at least at the time), where each block device would have a corresponding raw device with a fixed major/minor number. Personally I imagine that the lack of use of raw devices in Linux might have something to do with the strange way Linux raw devices work... Ambrose -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: blank=all only works in isolation
On Thu, Oct 21, 2004 at 07:08:06AM -0400, Rob Bogus wrote: If you found a bug in Linux which causes a panic I would be amazed if it doesn't get fixed. If you found an obscure feature which doesn't work, I can believe that without effort. Can you clarify? Yes. After the kernel panicked for a few times, I immediately did a Google search about the problem. The problem was already reported several times, and in a kernel developer's list I read that this problem was already known to Linux developers but will never get fixed. I don't think the problem is obscure at all; anyone who has a need of (or used to need and got into the habit of) burning HFS+ISO9660 hybrid CD's for Mac users and use ide-scsi (as opposed to ATAPI) would get into trouble. The problem, if I remember correctly, is that the a kernel rewrite during 2.3.x caused Linux to panic when the sector size of a CDROM mounted through ide-scsi is not a certain standard size, Linux developers did not consider fixing ide-scsi a high priority and the HFS driver was unmaintained. (Sorry about the lack of details, I tried to re-Google, but I could not come up with the right keywords. I'll try again later today to provide more details.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: blank=all only works in isolation
I'd disagree about its validity. Blanking a CDRW disc before writing sounded reasonable enough to me. I always thought that it didn't work because Linux was buggy. (About my Linux was buggy comment: I started noticing this after mounting HFS CDROM's started causing kernel panics, and afterwards found out that this serious problem was caused by a bug in Linux that is not going to be fixed. As for whether the blanking-then-writing worked before, I *think* I have seen it work before but, judging from what others are writing, I likely didn't remember correctly.) On Wed, Oct 20, 2004 at 01:25:46PM -0400, Mike 'Fox' Morrey wrote: Me neither. I know I had tried, and it didn't work, way before 1.0-final came out. I didn't complain because I figured that it wasn't valid - like you say, doing two steps at once.. Me. Under radio crackle, Bill Davidsen was decoded as saying:: Joerg Schilling wrote: none none [EMAIL PROTECTED] wrote: Seven years, fifteen different computers, twenty-five different Linux distributions, multiple types of cd burner (SCSI, IDE, USB), and every version of cdrecord and cdrtools I could find (both supplied with the distribution and compiled by myself). cdrecord -vv dev=1,0 blank=all /path/to/some.iso NEVER works. I typically get something like: Performing OPC... Blanking entire disk cdrecord: faio_wait_on_buffer for writer timed out. Blanking time: 1183.496s I never do this, and this may be the reason why nobody did complain before I didn't even know this was a supported operation... like you I've been doing it in two steps, back to the days when my Phillips 2600 SCSI drive was new stuff. -- ___ Mike 'Fox' Morrey - Noble Systems Director of Mad Science Programming Head of the Spontaneous Data Generation Department - Of all the things I've lost, I miss my mind the most. - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Burning an hfs filesystem without mkisofs
On Mon, Aug 23, 2004 at 10:40:15PM +0200, Andy Polyakov wrote: Does the fact that you pose this question mean that hfsutils do not generate partition table? Once again, this kind of goes beyond the scope of discussions on this list. I mean hfsutils maintainer is probably more appropriate persion to ask this kind of questions. A. Yes, according to the hformat(1) man page, hfsutils cannot generate the partition table. It knows what partition tables are, but it is not able to generate one itself. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux 2.6.8.1 requires changes to cdrecord (and probably every other CD/DVD writing app)
On Tue, Aug 17, 2004 at 01:13:23AM +0200, Joerg Schilling wrote: Linux(iirc since 2.2) supports a finer grained permission model than switching UID, POSIX capabilities[1]. Instead of switching to/from root bracketing each SCSI command you'd simply retain the necessary capability, CAP_SYS_RAWIO. cu andreas If Linux has this, why is there no documentation? Why is there no man pages for the Linux Kernel at all? There indeed is documentation (and man pages). Even I (not a developer of any kind to speak of) remember the original announcement (that capabilities have been implemented). The man pages are capget(2), capset(2), and capabilities(7). The capget(2) man page is dated 1999 and refers to ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs which is still valid. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems with TDK 440n DVD+/-rw
Hi, when Joerg says volume management, he does NOT refer to LVM/RAID stuff; he means automounters and things like that. (And my untrained eyes don't see anything wrong with the ps output. But you don't want to trust me here.) On Sun, Jul 18, 2004 at 01:28:34PM -0400, Dan wrote: On Sat, 2004-07-17 at 19:19, Bill Davidsen wrote: lsof and see what process is causing the problem. Here's a ps -A and lsof of when I kill as much as I can and still have the problem: [stuff deleted] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 100% system CPU usage with cdrecord
On Fri, Jul 02, 2004 at 03:15:31PM +0200, Joerg Schilling wrote: From: Ambrose Li [EMAIL PROTECTED] But note that if you use ide-scsi on 2.4, don't try to create HFS/ISO9660 hybrid disks. Otherwise your computer will lock up when you mount your disk to verify it. [...] I would not believe this unless you give an explanation. [...] I mentioned this in a previous post. It is a kernel bug in 2.4, and from what I found at that time through Google, it has something to do with sector sizes, and the Linux developers are not interested in fixing this serious bug. In fact, you answered my posting at that time: From [EMAIL PROTECTED] Tue Oct 14 11:54:55 2003 Date: Tue, 14 Oct 2003 17:54:34 +0200 (CEST) From: Joerg Schilling [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: linux kernel error reading end of cd/dvd Return-Path: [EMAIL PROTECTED] From: Ambrose Li [EMAIL PROTECTED] (From someone who doesn't know much about CD's) I used to checksum all the files (after finding that checksumming the whole disk doesn't work -- something beyond my understanding). This stopped abruptly after I upgraded my Linux kernel to 2.4, when mounting a hfs disk started to crash the kernel. I had to simply give people disks that I could not verify as having been written correctly. If your kernel did crash, then you definitely found a kernel bug. So if I might add something to the efficiency argument, I might add that for me to checksum my disk, I'll need to checksum all the files twice (once for iso9660, once for hfs), and all this is provided that checksumming all the files would actually work (which is not the case right now). IF you write in SAO mode and your drive is not broken (use -raw96r with Lite-ON drives for this reason), then you may simply checksum the complete content of the session. The CD definitely gives you exactly the same content back that has been in the *.iso file. 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: 100% system CPU usage with cdrecord
On Thu, Jul 01, 2004 at 04:21:24PM -0400, Rob Bogus mail account wrote: I *strongly* suggest using ide-scsi with 2.4 kernels. You want to boot with something like hdc=ide-scsi I believe, that what I use for all my working 2.4 systems. The device will probably be 0.0.0, but do check by looking at /proc/scsi/scsi to be sure. But note that if you use ide-scsi on 2.4, don't try to create HFS/ISO9660 hybrid disks. Otherwise your computer will lock up when you mount your disk to verify it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: plextor px-708uf: cannot get disk type
On Thu, Jan 29, 2004 at 11:05:41PM +0100, Joerg Schilling wrote: I just did run a test that verifies that the 708 in fact returns 36 bytes. So the problem is definitely caused by a Linux driver bug. I tend to believe that growisofs just does not check the SCSI status byte and for this reason is not aware of the problem. Sorry if what I say below is wrong, since I don't know what I am talking about. However, if the 708 really returns 36 bytes, I would say that one is not wrong to say that the 708 is buggy. Andy pointed out that the MMC standard *requires* the length returned to be 32+8*n (for some integer n) [section 6.26.2.1 Disc Information Length]. Since 36 is not 32+8*n for any integer n, 36 cannot be a valid value. As for whether growisofs does or does not check the status byte, since growisofs is open-source, anyone can just download it and see if it does the check or not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
I have a very high respect for Joerg. But please let me comment a little on this. Back in the former times (I started using GNU/Linux back when the only distros were SLS and Slackware), apps assumed that the kernel header files are in a linux directory in the system include path (the /usr/include/linux symlink, unless the user has a very strange setup). They need not assume there is anything in /usr/src/linux, though /usr/include/linux is likely a symlink to /usr/src/linux/include/linux. And I have never heard of anyone hard-coding /usr/src/sys (nor have I heard of such a directory at all) in their makefiles. I have never encountered any app that has such an elaborate setup to detect where the kernel include files are; I would tend to say that such elaborate setup is unnecessary. If the system in question is so broken as to not make the kernel include files accessible via a simple #include linux/some-file.h, it will have problems compiling all kernel-dependent software, not just cdrtools: Systems that are broken to such an extent do not deserve to be supported by an elaborate makefile system; a simple FAQ entry would suffice. On Sun, Jan 25, 2004 at 07:30:48PM +0100, Joerg Schilling wrote: You miss that in former times most Linux distributions in most cases did not include the needed include files at all in case the Linux kernel sources have not been installed at /usr/src/linux. The files in /usr/include/sys/ have been sysmlinks pointing to /usr/src/linux. Newer Linux systems tend to have real files in /usr/include. Some systems have neither symlinks nor files in /usr/include/sys. This is completely chaotic and the setup for Linux in the makefile system tries to do its best from this desaster. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Yes, myself is to blame for not checking the updated FHS. But why would anyone upgrading from libc5 to libc6 suspect that a change in the FHS should affect the upgrade (esp. if the libc6 docs do not refer to the FHS)? So my main complaint will be that I'll need to dig around per se, in unknown places for random upgrades. If upgrading to libc6 means I should rm the symlink, the libc6 docs should point this out, or at least refer me to the LHS. I didn't see either when I did the upgrade. On Tue, Jan 27, 2004 at 10:39:15AM -0800, Robert S. Dubinski wrote: The Filesystem Hierarchy Standard document version 2.3 of the Linux Standard Base project (http://www.linuxbase.org/) lists the following: usr/include : Header files included by C programs These symbolic links are required if a C or C++ compiler is installed and only for systems not based on glibc. /usr/include/asm - /usr/src/linux/include/asm-arch /usr/include/linux - /usr/src/linux/include/linux I read this as saying if you're using glibc at all you should no longer have or use the symlinks. Most modern distributions will both be using glibc and striving for LSB/FHS compliance. (I'm pretty sure if you dig around you'll find older PRs from RedHat/SuSE/Mandrake/Debian regarding LSB 1.0 compliance). -Robert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
I have a very high respect for Joerg. But please let me comment a little on this. Back in the former times (I started using GNU/Linux back when the only distros were SLS and Slackware), apps assumed that the kernel header files are in a linux directory in the system include path (the /usr/include/linux symlink, unless the user has a very strange setup). They need not assume there is anything in /usr/src/linux, though /usr/include/linux is likely a symlink to /usr/src/linux/include/linux. And I have never heard of anyone hard-coding /usr/src/sys (nor have I heard of such a directory at all) in their makefiles. I have never encountered any app that has such an elaborate setup to detect where the kernel include files are; I would tend to say that such elaborate setup is unnecessary. If the system in question is so broken as to not make the kernel include files accessible via a simple #include linux/some-file.h, it will have problems compiling all kernel-dependent software, not just cdrtools: Systems that are broken to such an extent do not deserve to be supported by an elaborate makefile system; a simple FAQ entry would suffice. On Sun, Jan 25, 2004 at 07:30:48PM +0100, Joerg Schilling wrote: You miss that in former times most Linux distributions in most cases did not include the needed include files at all in case the Linux kernel sources have not been installed at /usr/src/linux. The files in /usr/include/sys/ have been sysmlinks pointing to /usr/src/linux. Newer Linux systems tend to have real files in /usr/include. Some systems have neither symlinks nor files in /usr/include/sys. This is completely chaotic and the setup for Linux in the makefile system tries to do its best from this desaster.
Re: cdrecord-ProDVD and Liteon DVDRW LDW-451S?
Hi, On Wed, Jan 14, 2004 at 04:41:55PM +0200, Anssi Saari wrote: I tried reporting this, as Liteon actually has a problem report form on their website. Unfortunately it didn't work. I only understood the word 'Microsoft' from the error message, since my Chinese isn't very good. do you have the URL? Perhaps I can translate it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord-ProDVD and Liteon DVDRW LDW-451S?
Hi, On Wed, Jan 14, 2004 at 04:41:55PM +0200, Anssi Saari wrote: I tried reporting this, as Liteon actually has a problem report form on their website. Unfortunately it didn't work. I only understood the word 'Microsoft' from the error message, since my Chinese isn't very good. do you have the URL? Perhaps I can translate it.
Re: ide-scsi and 2.4 kernels
Yes, cdrecord can indeed use the ATAPI interface in 2.4 kernels, and I find it more reliable than using ide-scsi. I use it in both my work (whatever Sid has) and home (2.01a19) computers. In 2.2 kernels, ide-scsi is very reliable. However, in 2.4, I find that when I use CDRW media, the kernel would mysteriously crash; it crashes every time I use CDRW media (but works fine if I use non-rewritable CDR media). Also, HFS volumes cannot be mounted under 2.4 kernels when ide-scsi is used; doing so also causes a kernel panic. On Sat, Dec 13, 2003 at 09:56:25AM -0500, Rob Bogus wrote: I saw a claim that recent versions of cdrecord could use the ATAPI interface added for 2.6 in 2.4 kernels. Has anyone actually found this to be the case? As of 2.01a19 it seems to think the unit needs power cycling and can't do any operations. Why do I care? I wanted to see if audio burning with ATAPI mode would use DMA instead of PIO. Curiousity only, the ide-scsi is working fine. -- E. Robert Bogusta It seemed like a good idea at the time -- Ambrose LI Cheuk-Wing [EMAIL PROTECTED] http://ada.dhs.org/~acli/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ide-scsi and 2.4 kernels
On Sun, Dec 14, 2003 at 01:59:03PM +1300, Volker Kuhlmann wrote: In 2.2 kernels, ide-scsi is very reliable. However, in 2.4, I find that when I use CDRW media, the kernel would mysteriously crash; it crashes every time I use CDRW media (but works fine if I use non-rewritable CDR media). I have been using ide-scsi with an ide cd burner with SuSE kernels 2.4.18 - 2.4.20 and with an ide dvd burner on 2.4.20 and never had as much as a hint of a problem. Your problem may have to do more with your particular ide chipset than the ide-scsi module. It is possible, but I have the same problem with both my home and work computers. And both computers worked perfectly (with ide-scsi) when I used a 2.2 kernel. After upgrading to 2.4, at first I thought my computer broke down. -- Ambrose LI Cheuk-Wing [EMAIL PROTECTED] http://ada.dhs.org/~acli/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ide-scsi and 2.4 kernels
Yes, cdrecord can indeed use the ATAPI interface in 2.4 kernels, and I find it more reliable than using ide-scsi. I use it in both my work (whatever Sid has) and home (2.01a19) computers. In 2.2 kernels, ide-scsi is very reliable. However, in 2.4, I find that when I use CDRW media, the kernel would mysteriously crash; it crashes every time I use CDRW media (but works fine if I use non-rewritable CDR media). Also, HFS volumes cannot be mounted under 2.4 kernels when ide-scsi is used; doing so also causes a kernel panic. On Sat, Dec 13, 2003 at 09:56:25AM -0500, Rob Bogus wrote: I saw a claim that recent versions of cdrecord could use the ATAPI interface added for 2.6 in 2.4 kernels. Has anyone actually found this to be the case? As of 2.01a19 it seems to think the unit needs power cycling and can't do any operations. Why do I care? I wanted to see if audio burning with ATAPI mode would use DMA instead of PIO. Curiousity only, the ide-scsi is working fine. -- E. Robert Bogusta It seemed like a good idea at the time -- Ambrose LI Cheuk-Wing [EMAIL PROTECTED] http://ada.dhs.org/~acli/
Re: ide-scsi and 2.4 kernels
On Sun, Dec 14, 2003 at 01:59:03PM +1300, Volker Kuhlmann wrote: In 2.2 kernels, ide-scsi is very reliable. However, in 2.4, I find that when I use CDRW media, the kernel would mysteriously crash; it crashes every time I use CDRW media (but works fine if I use non-rewritable CDR media). I have been using ide-scsi with an ide cd burner with SuSE kernels 2.4.18 - 2.4.20 and with an ide dvd burner on 2.4.20 and never had as much as a hint of a problem. Your problem may have to do more with your particular ide chipset than the ide-scsi module. It is possible, but I have the same problem with both my home and work computers. And both computers worked perfectly (with ide-scsi) when I used a 2.2 kernel. After upgrading to 2.4, at first I thought my computer broke down. -- Ambrose LI Cheuk-Wing [EMAIL PROTECTED] http://ada.dhs.org/~acli/
cdrecord -scanbus strangeness?
Hello, sorry if this is a stupid question. I just downloaded cdrtools-2.01a20pre2 to try out its ATAPI support. (Linux 2.4's ide-scsi seems to be very broken.) I noticed the following: - cdrecord dev=help says bus scanning is supported for the ATAPI transport; - However, if I run cdrecord -scanbus, I just get Cdrecord-Clone 2.01a19 (i686-pc-linux-gnu) Copyright (C) 1995-2003 Jg Schilling cdrecord: No such file or directory. Cannot open '/dev/pg*'. Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. cdrecord: For possible transport specifiers try 'cdrecord dev=help'. strace seems to indicate that cdrecord stopped scanning after it failed to open the /dev/pg files. It may be this is the intended behaviour, but somehow it feels wrong that it would not scan ATAPI because it can't open the pg devices. Is this a bug, or is there some special notation I need to use to tell cdrecord to scan the ATAPI bus? (This is basically a DIY distribution, but I remember this also happening on my Debian box at the office. So I am suspecting that this behaviour is not related to the OS.) Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
cdrecord -scanbus strangeness?
Hello, sorry if this is a stupid question. I just downloaded cdrtools-2.01a20pre2 to try out its ATAPI support. (Linux 2.4's ide-scsi seems to be very broken.) I noticed the following: - cdrecord dev=help says bus scanning is supported for the ATAPI transport; - However, if I run cdrecord -scanbus, I just get Cdrecord-Clone 2.01a19 (i686-pc-linux-gnu) Copyright (C) 1995-2003 Jg Schilling cdrecord: No such file or directory. Cannot open '/dev/pg*'. Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. cdrecord: For possible transport specifiers try 'cdrecord dev=help'. strace seems to indicate that cdrecord stopped scanning after it failed to open the /dev/pg files. It may be this is the intended behaviour, but somehow it feels wrong that it would not scan ATAPI because it can't open the pg devices. Is this a bug, or is there some special notation I need to use to tell cdrecord to scan the ATAPI bus? (This is basically a DIY distribution, but I remember this also happening on my Debian box at the office. So I am suspecting that this behaviour is not related to the OS.) Thanks.
Re: linux kernel error reading end of cd/dvd
On Wed, Oct 15, 2003 at 12:33:12AM +1300, Volker Kuhlmann wrote: If we're talking about ISO9660 layout prepared by mkisofs, then those more blocks are known to be insignificant and you can as well checksum every file instead of the whole filesystem image, can't you? No. Checksumming only files does not checksum (all of) the filesystem's metadata. From an efficiency viewpoint, checksumming files is out of the question. Checksumming the disk is very fast, and independent of the filesystem used. In the case of iso9660, checksumming files may be slower by only a factor of two (sorry can't remember right now), for udf and ext2 you can plain forget about it from a practical perspective. The only fast way of doing it would be to read the whole CD/DVD image to disk, loopmount, check files - might check the disk itself in the first place. Does it really have to be whole image? Yes. And it *ought* to work ;) (From someone who doesn't know much about CD's) I used to checksum all the files (after finding that checksumming the whole disk doesn't work -- something beyond my understanding). This stopped abruptly after I upgraded my Linux kernel to 2.4, when mounting a hfs disk started to crash the kernel. I had to simply give people disks that I could not verify as having been written correctly. So if I might add something to the efficiency argument, I might add that for me to checksum my disk, I'll need to checksum all the files twice (once for iso9660, once for hfs), and all this is provided that checksumming all the files would actually work (which is not the case right now).
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
On Tue, Jul 01, 2003 at 06:46:50AM -0400, [EMAIL PROTECTED] wrote: The implementation of associated files is exactly that of subsequent extents (aside from ordering). My question was intended to read What effect does that Linux option have, with regard to handling multiple extents. Is there similar confusion, or is that part better documented. From a user's viewpoint, no, it is as poorly documented. The user documentation for the unhide option, in its entirety, is as follows: unhide Also show hidden and associated files. There may be some docs in the kernel source, but I think for the user, having to look there is a bit too much. -- Ambrose LI Cheuk-Wing [EMAIL PROTECTED] http://ada.dhs.org/~acli/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
Hi, On Mon, Jun 30, 2003 at 02:52:50PM +0200, Joerg Schilling wrote: I did submit a bug report; the man page should mention this in the future... Not a thing that the mkisofs man page should mention, is it just not related to mkisofs. If ever, it is related to the way Apple implemented it (so look at Apple documentations). sorry for not being clear enough. I did submit a bug report for the Linux mount(8) man page. I believe it is more of a bug on the Linux side, though some extra notes on the mkisofs side would certainly be nice for clueless users (like me). Best regards, -- Ambrose LI Cheuk-Wing [EMAIL PROTECTED] http://ada.dhs.org/~acli/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
On Fri, Jun 27, 2003 at 11:40:59PM -0400, Rob Bogus wrote: The user deliberately selected an option to make those forks visible. Linux doesn't (deliberately) make things dificult, it just makes the default safe in most cases, and allows you to make a choice. If you ask to see the fork you can't complain that the fork is visible. Yes, that's why I say it is my fault but also a bug in the Linux docs. As someone who does not know all the details of the ISO9660 standard, one would never have thought that the resource fork and the data fork would have the same name and therefore the resource fork would make the data fork invisible. Certainly the user (myself) made a stupid choice, and the choice is made because the documentation did not make it clear that the option is unsafe. In fact, I did read all of the mount and mkisofs man pages, and still made this stupid choice, perhaps it is not unreasonable to say that the docs *are* unclear. I did submit a bug report; the man page should mention this in the future... Best regards, -- Ambrose LI Cheuk-Wing [EMAIL PROTECTED] http://ada.dhs.org/~acli/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
Hi, On Mon, Jun 23, 2003 at 03:44:35PM +0200, Joerg Schilling wrote: mkisofs has passed the compliance test for Picture CDs from Kodak. If you have problems without using HFS, they are definitely a result of a Linux bug. the corruption does not happen without using HFS unless I also use -apple. It only happens if I tell mkisofs to look for Apple resource forks. I have found the cause of the corruption. It is indeed a Linux bug, or perhaps more accurately a bug in the Linux mount(8) manpage. If I use the unhide mount option in /etc/fstab, Linux will pick up the resource forks (probably because they have the same filenames as the corresponding data forks) instead of the data forks, causing the corruption. The corruption stopped occuring after I removed the unhide option from my /etc/fstab. I originally added the unhide option in an attempt to also show the resource forks when I mount the CD under Linux; obviously that doesn't work. I wonder if it is technically possible for mkisofs to somehow write the iso image in a way that can prevent this from happening, even though it is obvious now that it's the user's (i.e., my) fault. Thanks very much for the answers, -- Ambrose LI Cheuk-Wing [EMAIL PROTECTED] http://ada.dhs.org/~acli/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
strangeness when writing iso9660/hfs hybrid disks
Hello, I have written a few hybrid disks (iso9660+Joliet+HFS) with mkisofs/cdrecord, and I just discovered something very strange. After the disk is written, I can mount the disk from Linux (2.2.25, glibc 2.2.5) in iso9660 mode. However, for files that originally have a Apple resource fork (from Netatalk), it seems that the resource fork instead of the data fork is visible to Linux. Stranger still, this does not happen if I mount the CD image file instead of the CDROM disk. It seems that mkisofs generates identical inode numbers for both forks (in iso9660 mode), and the way the files are laid out are making at least the Linux kernel confused. I have narrowed it down to the point where I can say that this happens only if I use -hfs or -apple. If I produce a pure iso9660 disk, then the files are not corrupted. I wonder if anyone knows whether this is a known mkisofs/ cdrecord bug, a previously unknown bug, or it is something that I did wrong. The cdrtools version I have used are 2.00.3 (latest stable version) and 2.01a16 (latest testing version). Best regards, -- Ambrose LI Cheuk-Wing [EMAIL PROTECTED] http://ada.dhs.org/~acli/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
