l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2008 Oct 31 14:46

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



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.

Alex
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
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:
EDGE Tech Corp.
For donating some give-aways for our meetings.