me > > Therefore the constraints with my advice to write the tar.gz file > > to DVD without an ISO wrap. That would be readable on any Unix. Helmut Jarausch > Yes and No, > Since there is no notion of a file length and most of the time > I get LOTS of errors and the end of the file when reading from a > raw CD.
But tar knows when it reaches the end of an archive. So the file length is not really in question. You describe the annoying read-ahead bug which is not specific to the data format but to CD reading on Linux. (I do not experience it with growisofs written DVD+RW on Linux) The workaround is to add some padding. cdrecord option padsize=128k seems to be enough for even the most eager read-aheaders. One usually does not experience trouble with ISO filesystems on CD because mkisofs adds a generous amount of padding by default. (300 kB according to 2.01a35's man mkisofs, option "-pad") me > > > > I cannot imagine a method to mix on-the-fly file parts > > with usual mkisofs input from disk directories. Or to fiddle > > disk directories into something like -stream-media-size :( > Helmut Jarausch > > What's the problem? > If both parts reside on the same volume (DVD) > e.g. as B.tar.gz.1 B.tar.gz.2 > cat /dvd/B.tar.gz.1 /dvd/B.tar.gz.2 | tar xzf - The problem is about writing pieces of large files. Not about putting them together. With my ISO backups there is no intermediate archive format. The files are randomly accessible on the media with any computer system which knows about ISO. Put in the media and click on files - that's how the Windows users want it. Admins of Samba servers show their loving care to their clients by handing over personal backups or emergency DVDs for the case that the server is down. For a Linux user it is still a fine feature to work with usual programs directly on CD rather than having to extract files from a backup archive to hard disk. My technical problem : With mkisofs i know the traditional way to give addresses of files or directories existing on the hard disk as input (pathspec). There also is a stream input mode which produces an ISO image containing a single file (-stream-media-size). Paul Serice's flyisofs can produce several files (in a single directory, using something like multi-session chaining, if i got it right). But this is not suitable for tens of thousands of single files. It would be a very unusual ISO image layout (including the 4 GB inode problem on older Linux) and i guess there would be other drawbacks. None of these models suits my dream. I read and squeeze man mkisofs in the hope to find a hint for a solution - no success up to now. Joerg: i would love to get an RTFM if there is any way to construct a mkisofs pathspec that does not describe the whole file but only a specified piece of it. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
