Quoting Volker Kuhlmann <[EMAIL PROTECTED]>: > Are you sure? Joliet is an optional extra, on unix it's just a waste > of space.
Joliet extensions have various limitations on file paths and names. I run into them regularly. Not using Joliet fixes the issue (bare ISO9660 or ISO9660+RockRidge-only). > Unless you have specific reason to have a tar format on disk, you > could just skip making the tar file. If you're dealing with a file larger > than a DVD, the raw method is to use split (and copious quantities of > md5sum and disk space). Remember, ISO9660 (and UDF) is an archiving format** on its own. When you use another archiver, you "double archive" which results in increased recovery time to "unarchive." [**NOTE: This doesn't make sense until you realize the "imaging" operation is the "archiving" and the "recording" is the "extraction." Then it makes total sense. CD/DVD is an archive media that is random-access, unlike tape and other sequential methods ] > Am I the only one who finds that Linux is now too crappy to read > CDs/DVDs? Most of the time I get an error with that. Kernel 2.4.20. Nope. I've just had issues with my Matsushita LF-D310 (3G DVD-RAM) lately. It's not even a year old. A CD-RW and DVD-ROM drive in the same system has no issues. > md5sum is twice as fast as cmp, as cmp needs to read both sets of > data, md5sum only one. Compared with the time it takes only one set of > data, the time of computing the md5 is insignificant. I've done some benchmarks of 128-bit MD5 via md5sum and 16/32-bit CRC via checksum. No difference in speed on modern x86 CPUs AFAICT. -- Bryan J. Smith, E.I. mailto:[EMAIL PROTECTED] http://thebs.org _______________________________________________ Dvdrtools-users mailing list [EMAIL PROTECTED] http://mail.nongnu.org/mailman/listinfo/dvdrtools-users
