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 >