Prev: Sabre: ARM computer reference released
Next: Getting screen resolution from a script
From: Ben Davis on 5 Jan 2010 09:50
Robert Billing wrote:

> I wrote a thing called tsplit that can split a stdin of any length into
> lots of equal sized files, then reassemble. I use it to split tar/bzip
> output for backup. Is this what you meant?

Wanted something more like datapack[1] which I found later - create
several abritraily<sp?> sized container dirs of hard/symlinks to
original files - so I pipe the output of find -type f blahblah* into it
and I can get several ~4gig dirs for writing to dvd's (for example).
There's also a perl module around called archive2iso[2] which does the
same apparently. Thanks anwyay ;)

[1] http://software.complete.org/datapacker
[2] http://www.ugu.com/archive2iso

Regards....j

--
** Ben aka Jamin Davis @ Home :::: jamin(a)ghost.merseine.nu **

[ http://jaminja.wordpress.org ]
From: chris on 5 Jan 2010 10:34
On 05/01/10 14:50, Ben Davis wrote:
> Robert Billing wrote:
>
>> I wrote a thing called tsplit that can split a stdin of any length
>> into lots of equal sized files, then reassemble. I use it to split
>> tar/bzip output for backup. Is this what you meant?
>
> Wanted something more like datapack[1] which I found later - create
> several abritraily<sp?> sized container dirs of hard/symlinks to
> original files - so I pipe the output of find -type f blahblah* into it
> and I can get several ~4gig dirs for writing to dvd's (for example).
> There's also a perl module around called archive2iso[2] which does the
> same apparently. Thanks anwyay ;)
>
> [1] http://software.complete.org/datapacker
> [2] http://www.ugu.com/archive2iso

Those links look very useful. Thanks for posting them!
From: Chris Davies on 5 Jan 2010 10:26
Bernard Peek <bap(a)shrdlu.com> wrote:
> I've been looking for a similar sort of script [...]

> The idea is to run a script that copies files to the DVD so that
> individual files can be browsed and recovered.

Mondo?

Chris
From: Denis McMahon on 5 Jan 2010 12:10
Bernard Peek wrote:
> On 05/01/2010 12:18, Robert Billing wrote:
>> As the bottle floated ashore we opened it and found the message that
>> Chris
>> Davies had written:
>>
>>> Robert Billing<unclebob(a)tnglwood.demon.co.uk> wrote:
>>>> I wrote a thing called tsplit that can split a stdin of any length into
>>>> lots of equal sized files, then reassemble.
>>>
>>> Sounds like split(1) to me?
>>> Chris
>>
>> Tsplit is my version that can do things like ejecting media between
>> files.
>> Same general idea, I just added some features.
>
> PMFJI
>
> I've been looking for a similar sort of script but I may have developed
> the idea a bit further. I'm pretty sure that this is not a trivial
> project, but it seems to me the perfect backup solution for home users.
>
> The idea is to run a script that copies files to the DVD so that
> individual files can be browsed and recovered. Files should never be
> split between disks unless the file is larger than a disk's capacity.
> Ideally packing should be optimised: if the next file will not fit into
> the free space then the script should look ahead to find a file that
> will fit.
>
> It would be nice if the script could compress certain types of file but
> this is just as easily handled in other ways.
>
> The script should ideally log its actions, producing a report that
> details which file is on which disk.
>
> It would be nice if the script, given enough disk space, could run
> unattended and generate a set of .iso images ready to write to DVD in
> one session.
>
> It would be nice if the script could connect to unmounted Samba shares
> but that sounds like a security risk so I'm doubtful whether this is
> practical.

Hmm

command output_media_size input_filespec_list

Generate the list of input files, get their sizes.

Start with files bigger than output_media_size and split them into
chunks of output_media size.

Now you have a list of files each of which is equal to or smaller than
the output media size.

Put each of the single media files on a media.

Now, for each extra media that you use, keep adding the biggest file
that will fit in the remaining space until either the media is full or
you can't find a file small enough to fit in the remaining size. Then
start the next media.

This is likely to make finding specifc files across the media collection
tedious, but will be the most efficient use of the media.

Rgds

Denis McMahon
First  |  Prev  | 
Pages: 1 2
Prev: Sabre: ARM computer reference released
Next: Getting screen resolution from a script