> 1. Have the bugs Volker encountered with UDF been fixed now? Volker, > what versions of kernel and udftools were buggy for you?
Whatever was current at the time... ;) Seriously, must have been SuSE 8.2, kernel 2.4.20, udftools 1.0.0b2. > 2. How does UDF fare as far as faithfully preserving all the ext2 > attributes (uids, permissions, hard/soft links, pathname lengths, > etc.)? That's the problem. I went off iso9660 because it doesn't restore hardlinks (its other shortcomings are masked well by rockridge). With udf back then I tried a cp -a into a loop-mounted udf fs, and when comparing directories some symlinks were missing. Running rsync over it fixed it, but I didn't feel like it was really backup quality. I can't say whether things have improved but I somewhat doubt it because nobody is working on it. Back then I found it impossible to dig up any good information about udf, there wasn't even documentation which explained the mkudffs options! mkisofs is only good for video disks and crude backups because it doesn't retain uids. You also have serious performance issues with Linux udf on an optical disk when reading. Some very simple tests resulted in no gain of udf over ext2 on average. Both could kill your drive before you're done reading if you're unlucky. There is a good reason why mkisofs carefully lays out the blocks for iso9660. > 3. How exactly are we supposed to determine/control the size of the > filesystem and image file? > (a) Is there a table/chart that shows the number of blocks of all > the common optical media (74min CD, 80min CD, 4.7GB DVD, etc.) > or is there some way we can get this from the /dev (loaded with > "blank" media) itself? All blanks I have ever come across (22 different types, I kept careful record) had the same capacity: 2298496 for DVD-, and 2295104 for DVD+. I've read the nominal capacity is 4.7^ bytes, but that doesn't divide by 2048 (and the media's block size is 32k anyway I think) so there must be some fudge factor. dvd+rw-mediainfo (and cdrecord-prodvd) show the exact number of available blocks of an inserted blank. Dito cdrecord for CDs. > (b) The ISO filesystem seems not to have a problem with image files > that are smaller than the target media. Is this true with UDF > and ext2 as well? Yes. It is irrelevant of the filesystem. View the optical media like a hard disk - there are a certain number of blocks in both. How you use those blocks is up to you. You can burn reiserfs if you feel like it. Or tar. Or cat /usr/bin/* | growisofs -Z /dev/burner=/dev/stdin. > (The answer might seem to be an obvious "yes", > but I don't want to assume that the image file size is identical > to the concept of a partition.) ??? You have always been able to create a filesystem in /dev/hd3 which is smaller than the size of /dev/hd3. Hard disk partition sizes are an upper limit. Likewise for optical media size. > (c) If so, how do we best go about resizing the filesystem as well as > its containing image file to match the actual storage requirements > of the files to be archived? (So that our .img files can be smaller > than the target media if we don't fill it all.) IMHO, it seems to > me that the minute "mount -o loop" became possible under Linux, we > should have had the tools to manage filesystem and image file sizes > for all of the supported filesystem types. In an ideal world, yes... Barring the obvious restrictions, like iso9660 never being able to be writable (in pratice). In the real world, volunteers are always welcome. ;) It also seems to me that burning is a desktop application, and Linux is still a bit lacking there. I can't find a better explanation than that either for the fact that when burning N blocks onto a CD, Linux can't even read all of them back before strangulating itself (sounds incredulous, but is true). The alternative would be to implement a filesystem which can achieve say 2/3 of burn speed when copying files into it, making use of DVD+RW and random access writing. I've settled on ext2, and have a bunch of scripts for creating the filesystems. It's not too bad really when comparing with alternatives. > Of course, I am sure things get a lot more complicated by the filesystem > "growing" or appending required for multisession recording of nonrewritable > media. UDF may allow for a "growudffs" approach, but I doubt if ext2 can. "Growing" in multisessions requires a filesystem which is specifically designed for this. Hard disk filesystems are not. Dunno about udf. For anything but iso and udf you will have to rewrite the whole filesystem, or use random access writing on DVD+RW. I don't consider CDs any more in this, their capacity is so small, you can blockread, modify, and burn with a bit of scripting in little enough time. Linux has missed the boat there. 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]