On Fri, Mar 21, 2014 at 8:57 AM, Fred Smith <fredex at fcshome.stoneham.ma.us>wrote: > On Fri, Mar 21, 2014 at 10:55:33AM +0000, Andrew Holway wrote: > > Dear Bonnie, > > > > Your not getting an answer because the emails you are sending look > > like spam to most email filters. > > > > Thanks, > > > > Andrew > > > > > > > > > > > > On 18 March 2014 09:22, Bonnie B Mtengwa <bmtengwa at potraz.gov.zw> wrote: > > > I have a file Server CentOS 5.10, its on the internet, so I compress > all csv > > > into one file using (tar -czvf compressed_files.tar.gz *.csv) on this > > > server so that I can download them as one compressed file to save > bandwidth, > > > Disk space on this server available is 50Gig, so when I copy the files > onto > > > Redhat EL 5.9 and decompress them using (tar -zxvf *.gz) It > decompresses > > > maybe 80% then get error: > > > > > > > > > > > > gzip: stdin: unexpected end of file > > > > > > tar: Unexpected EOF in archive > > > > > > tar: Unexpected EOF in archive > > > > > > tar: Error is not recoverable: exiting now > > > > > > > > > > > > what might be the issue here? > > Wild guess: > Is the file, by anychance, somewhat over 4 gigs? > Our grandfathered homegrown backup solution that is in place for web hosting at work tars up customer web content, which ends up being 15GB in some cases. And it's web content, so there's lots of files! I'm sure if I took the time, I might find an even larger tarball -- but 10-15GB is pretty hefty. I've had a problem, years past, when a particular compression tool > Would you kindly share the name of the compression tool? > blew up on files over 4 gigs, because it requires an integer > larger than a 32-bit int to hold the file offsets. I wouldn't > really expect that to be a problem on Centos 5.x, even on a > 32-bit system, but one does wonder.... > However ... we have a mix of 32-bit and 64-bit CentOS 5.10 systems that create the backups (I speak of above) without a problem. So 32 vs 64-bit may not be the cause. -- ---~~.~~--- Mike // SilverTip257 //