> Therefore, I use the following procedure (with Andy Polyakov?s patch applied)
You don't need the patch for that. What you're doing is creating the filesystem in a loop-mounted file, then burning that file as disk image. Whether you start with an empty file or with a disk image read from an existing disk is irrelevant. Btw the truncate function of the C-library is very handy for creating humangous empty files. Also, you can use any filesystem you like, except iso9960 because that can't be mounted readwrite. Unfortunately, this is the only method with actually works on Linux. Andy's kernel patch is brilliant, if you only want to make small modifications it's very good. For larger changes (certainly when many files are involved), random access writing on Linux is a non-event from a practicality point of view. Btw the udf filesystem itself is buggy too when writing - about 10% of my symlinks get chopped and point to the empty string. This can be fixed by another run of rsync. I did some qad speed tests on ext2 and udf, and found that with both, depending on read operations, the whole thing can grind itself to a halt. Neither was outstandingly better than the other for DVDs/CDs. However, ext2 has other significant advantages: 100% bug free, e2fsck, resize2fs, useful documentation. When I had to start a scratch a third time because the udf filesystem I created was yet again a few MB too small I decided to udf = RIP. This was helped by the fact that there is no information on how to use the options of mkudffs in google, nor was that question of mine answered by anyone on this list. Ext2 uses less space for itself than udf if you reduce the number of inodes to something approaching what is actually used. You also might want to consider copying files into the filesystem in alphabetical order, it'll speed up reading in some cases. I do this by creating an empty filesystem (loop mount) and copying the files into it, umount, and burn. This should also defragment ext2 a bit. There's a script (yes, correct - there is no single command which can actually do this, and you have to do it as root) called cp-sort in the scriptutils package on my website (it also contains a wrapper-script to the truncate system function). Using growisofs -M is an alternative (which I haven't tried myself but expect to work). As you observe, mkisofs -udf doesn't yet cut it. That leaves mkisofs with iso9660 - a fine solution, *unless* you want to store hardlinks. To be precise, you can *store* them, just not read them. This is a bug in the Linux iso9660 for which there is no general solution available, and won't be either. The only hope here is someone making another mount option and mod to the iso9660 which can handle hardlinks, at the expense of a small risk that some Microshite CDs won't read any more properly with this thing turned on. The packet writing driver fares much worse. I can copy a CD image to disk, make changes, and burn it back in less than 10 minutes. Writing 400MB (I think) onto a cd-rw with the packet driver takes 45 minutes. Not mentioning the kernel panics and the corrupted files on the CD, it's maybe something for kernel 2.8. Linux is trailing M$ by a large number of years by then. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
