Hi, > For my own history I have been using tar output piped to sdd to be directly > written using the raw device drivers for about 3 years now I think on many > servers. This use requires a kernel patch available from Andy for 2.4 > series kernels and 2.6 series kernels have not required a patch.
That explains why i never was aware of a generally DVD+RW device file. From time to time i read some rumors but always ended up at Andy's patch (which is obsolete if you can restrict yourself to sequential streams and use growisofs) or at udf-tools which seem to need a 2.4-kernel patch too. Their writing method seems to use raw devices and offer access to CD-RW and DVD+RW. Naively one would expect that there are CD- and DVD- devices in an OS like there are devices for disks and tapes and whatever strange hardware. Somehow this idea did never really succeed in reality. :( > If I > recall from when Andy added this feature I think the operation is > independent of the structure of the incoming data so I think it should > work for my purposes. Yes. For me it works with ISO9600 or afio format as well as with permuted and multiplied images. So one can say that it accepts any stream. I encountered the neglible problem that it interprets eventual ISO filessytem headers and prints misleading progress information in case that further data are appended to the ISO image. (In my case checksum information or further copies of the image) It also seems not always to exit with an error indicating value on failure. Another thing is that you need a file object that delivers the standard input of the process (/proc/self/fd/0 or /dev/fd/0 on my Linux) if you generate the data stream on the fly. > For data backup purposes, it makes no sense to use the > additional overhead and file handling to format an ISO image unless it is > intended to be read from another OS platform that does not have a direct > capability like in Windows. ISO trees have advantages in case of smaller data mishaps. For example the files are accessible by arbitrary clicky-colorful filemanagers. (Very important for KDE users :)) ISO also allows to test backuped files with their original application programs. (Very important feature to soothe the scruples of people who already suffered from unreadable DAT tapes or similar backup bloops.) On the other hand the pitfalls of ISO (and in part of mkisofs) cannot be ignored when it comes to backups of non-data files, deep trees, wide trees, to preservation of access permissions, or error recovery with damaged media. On a backup area with completely arbitrary file objects i use the traditional archiver afio. It serves me since the days of DC-6150 tapes. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
