l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2008 Oct 31 17:10

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] burn directories to CDs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] burn directories to CDs

On Tue, Oct 28, 2008 at 07:22:49PM -0700, Alex Mandel wrote:
> Jeff Newmiller wrote:
> > harke wrote:
> >> On Tuesday 28 October 2008 08:49, Tim Riley wrote:
> >>> On Mon, 2008-10-27 at 18:56 -0700, Jeff Newmiller wrote:
> >>>> harke wrote:
> >>> <snip>
> >>>
> >>>>> You could use cpio with the pass-through option. his does
> >>>>> not use or create an archive. You'll probably need some other options
> >>>>> like make-directories
> >>>> I am mystified why (or how) one would use cpio to copy files to a cdrom.
> >>>> Can you elaborate?
> >>> $ find . -print | cpio -p /dev/cdrom ? ;-)
> >>>
> >> You'll first need a file system on the cd
> >> so you could do
> >>      mkfs -t ext2 /dev/cdrom
> >>
> >> Notice that it is perfectly feasible to put an ext2 file system
> >> on a cd Of course certain other operating systems will not be
> >> able to read it.
> >>
> >> If you prefer to stick to an iso file system, just use the usual tools.
> > 
> > I suppose if you want to be obscure, dumping data to /dev/cdrom is
> > one way... I prefer making my backups as self-documenting and simple
> > as possible.
> > 
> > I also recognize that it is feasible to put alternate filesystems on a CDR,
> > but the above mkfs command won't work, given the fact that any data written 
> > to a CDR must be written in one pass with no modifications, and mkfs lays
> > out data structures throughout the device file in random access fashion
> > with the expectation that data and directory entries will be modified later.
> > 
> > I think Brian's requirement to support multi-disk backups in standard
> > directory layout is a tall order... though there might be a tool out there
> > that supports this.  Seems like it would be hard to allocate disk usage
> > among small and large files in arbitrary directories on multiple volumes.
> > Read-only LVM? (very obscure... why bother with the directory structure?)
> > 
> This reminded me, back in the day when you could span zip files at
> 1.44MB in order to put it across multiple floppies.
> And hence a solution...
> tar them with a max size option, the archive will be split at the given
> size and start a new file.
> http://www.base64.co.uk/splitting-large-files/
> Maybe not exactly browsable, but probably so from a graphical archive
> tool except for the 1 split file between the spans.

No, no, no. This is a very simple problem. No splitting of files is
allowed. These are all files that will fit within one CD.


K3b doesn't seem to work, and the multicd seems to still use commands
from 2001. It refers to the CD burner as a scsi device. But, I can
probably hack multicd. I just want a CD I can put in the CD drive and
browse the files so that they are in the same directory structure as

Brian Lavender
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.