RE: Newbie: -tsize vs -j
<[email protected]> Sun, 23 Apr 2006 11:47:48 -0400
| Newsgroups | gmane.comp.archivers.star.user |
|---|---|
| Message-ID | <000201c666ed$48d3f310$0601010a@DEV5> |
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 -- EMail:[email protected] (home) Jörg Schilling D-13353 Berlin [email protected] (uni) [email protected] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily