RE: Newbie: -tsize vs -j

Daniel Davidson <[email protected]> Mon, 24 Apr 2006 10:48:32 -0500
Newsgroups gmane.comp.archivers.star.user
Message-ID <[email protected]>
Couldn't you also write a script that keeps adding files one at a time
to the archive until say the archive's current size plus the size of the
new file is greater than your file limit.  Then you could just start a
new file.

That would approximate what you want to do at the cost of increased
processor usage and disk I/O.  But if you are writing files to cd/dvd,
that should not be such a big deal.

I haven't tried this though, so I might just talking out my rear.  If
you can go to tapes, this becomes much easier to do.

Dan


On Sun, 2006-04-23 at 11:47 -0400, [email protected] wrote:
> I'm trying to get cd or dvd size archive files using star. Star is 99.9%
> perfect for my use. With -j I guess the -tsize becomes a not-to-exceed-size.
> 
> I don't want to use "split" since a single media failure in the middle would
> make recovery of later blocks tough.
> 
> The .1% issue:
> 
> I guess I'll just write a shell script to take multiple archive files to
> make the iso. I'll have wasted space on the cd/dvd - but if I make tsize
> 200m it should only be about 100m. 
> 
> Do you see a better way?
> 
> I appreciate your time. 
> 
> -----Original Message-----
> From: Joerg Schilling [mailto:[email protected]] 
> Sent: Sunday, April 23, 2006 7:03 AM
> To: [email protected]; [email protected]
> Subject: Re: [Star-users] Newbie: -tsize vs -j
> 
> 
> <[email protected]> wrote:
> 
> > Thanks for star - looks like it will work for my file archiving
> > requirements.
> >
> > Is there a way to have the -tsize value be evaluated after compression? 
> >
> > Using this command: 
> >
> > /opt/csw/bin/star -cj -tsize=700m \
> > -multivol -dump -M \
> > -C=/usr \
> > new-volume-script=nf.sh \
> > -acl -artype=exustar f=f001 f=f002 f=f003 f=f004 f=f005 f=f006 f=f007 \
> > level=0 -time .
> >
> > Produces the following files:
> >
> >  253963147 Apr 14 10:58 f001
> >  180915793 Apr 14 11:01 f002
> >  257749914 Apr 14 11:05 f003
> >  279395825 Apr 14 11:10 f004
> >    1580019 Apr 14 11:10 f005
> 
> This is the expected behavior.
> 
> > I was expecting each full file to be 734003200 bytes. 
> 
> Why? You don't see the archives but compressed variants....
> 
> If it wiould refer to the size past compression, your wich from below would
> not be possible to implement.
> 
> > Also, is it possible to restore a multi-volume archive without some of the
> > volumes?  In other words, if a media error prevents part 2 from being
> > recovered, will parts 3 + be recoverable?
> 
> You will be able to recover the files (see man page) but not be able to 
> do the special actions that are needed for incremental restores.
> 
> ---> All file content on the "good" parts of the tape is restorable
> 
> ---> implicit additional information is lost.
> 
> Jörg
>