What version of gzip are you using? From www.gzip.org:
gzip 1.2.4 may crash when an input file name is too long (over
1020 characters).
not in my case.
The buffer overflow may be exploited if gzip is
run by a server such as an ftp server. Some ftp servers allow
compression and
Check for root kits?
Try the same operation on a known working system, take that output
file and do a diff with that and the corrupt one after a 'strings', so
'strings new.gz new-text', 'strings corrupt.gz corrupt-text',
'diff new-text corrupt-text'. I'm just interested in how it's being
Try the same operation on a known working system, take that output
file and do a diff with that and the corrupt one after a 'strings', so
'strings new.gz new-text', 'strings corrupt.gz corrupt-text',
'diff new-text corrupt-text'. I'm just interested in how it's being
corrupted and maybe
available. At least some of your utilities in /usr/bin are statically
linked.
In 5.5 the statically linked utilities are in /stand, while dynamically
linked versions of the same are in their normal places.
OK.
-r-xr-xr-x 30 root wheel 2046148 Nov 4 2004 /stand/gzip
I would expect
On Fri, May 04, 2007 at 01:42:59PM -0400, David Banning wrote:
What seems strange is that the failure is not a massive failure
the gzipped and then gunzipped file is only 2 bites difference
on a 3G file. I am wondering now if something could be amiss in
my BIOS - any thoughts here?
FreeBSD
On Fri, May 04, 2007 at 01:33:09PM -0400, David Banning wrote:
first time I have tried files of this size - but I get the same
problem no matter what compression utility I use; tried gzip, bzip2,
rzip and compress.
Which is why I suspected a corrupted library and asked that ldd(1) be
run on
David Banning wrote:
I am attempting to zip large files that are 2GB - 3GB.
If you wish to exclude the disks completely, you can try generating a
large file on a known-good host and running md5 on it, then reading it
via NFS on the suspect machine, piping through gzip and gunzip, and
right into
I have replace my memory. It didn't make any difference.
root# gunzip *ian_mail*
gunzip: 3s1.com-ian_mail-full-20070503-0105AM.1.tgz:
invalid compressed data--format violated
root#
and another way;
root# tar tzf *ian_mail*
lists most files in the tgz, then terminates with;
...
tar: Skipping
On Thu, May 03, 2007 at 01:48:43AM -0400, David Banning wrote:
I have replace my memory. It didn't make any difference.
root# gunzip *ian_mail*
gunzip: 3s1.com-ian_mail-full-20070503-0105AM.1.tgz:
invalid compressed data--format violated
root#
and another way;
root# tar tzf
On May 2, 2007, at 11:41 PM, David Banning wrote:
I haven't been paying 100% attention. Just how does it fail? What
do you
mean by corrupt?
Does the process run to completion?
All programs zip with no errors. On reading;
root# bzip2 -t zippedfile.bz2
bzip2:
David Banning wrote:
I have replace my memory. It didn't make any difference.
root# gunzip *ian_mail*
gunzip: 3s1.com-ian_mail-full-20070503-0105AM.1.tgz:
invalid compressed data--format violated
root#
and another way;
root# tar tzf *ian_mail*
lists most files in the tgz, then terminates
Correction:
On Thu, May 03, 2007 at 07:10:37AM -0500, David Kelly wrote:
Can't keep from thinking somehow your hardware is broken because
myself and others have been gzip, bzip, zipping, large files for a
long time under FreeBSD without problems. BUT on 6.0 I had
intermittent problems
gzip: stdin: invalid compressed data--format violated
tar: Child returned status 1
tar: Error exit delayed from previous errors
root#
Unless you can demonstrate some other systematic effect (e.g. always
truncated at the same size), it looks like you have some other kind of
failing
David Banning wrote:
gzip: stdin: invalid compressed data--format violated
tar: Child returned status 1
tar: Error exit delayed from previous errors
root#
Unless you can demonstrate some other systematic effect (e.g. always
truncated at the same size), it looks like you have some other kind of
On 2007-05-01 15:58, David Banning [EMAIL PROTECTED] wrote:
I am attempting to zip large files that are 2GB - 3GB.
uname -a;
FreeBSD 3s1.com 4.11-STABLE FreeBSD 4.11-STABLE #7
I have tried gzip, bzip2 from the ports and rzip.
All give no errors on zipping, but will not unzip, siting CRC
Maybe you have defective RAM in the upper memory area.
Try running MEMtest86 to see you have some bad memory.
You may have something here. I don't have a floppy on this machine,
and I can't shut down my server to test the memory but I may shut
it down long enough to swap the memory chips so I
A lot of the features related to file sizes and other attributes
of the files stored on a disk depend highly on the type of file
system used on the disk.
What file system does the destination directory live in?
originally my problem was with a dedicated ide (on ide cable in machine)
On 2007-05-02 12:26, David Banning [EMAIL PROTECTED] wrote:
Giorgos Keramidas wrote:
A lot of the features related to file sizes and other attributes of
the files stored on a disk depend highly on the type of file system
used on the disk.
What file system does the destination directory live
originally my problem was with a dedicated ide (on ide cable in machine)
secondary mounted drive - 300G
I tried it in /usr with same results.
The disk type isn't really what I asked about. Is your /usr file system
mounted from UFS (I haven't kept all the messages of the thread, so I
On Wed, May 02, 2007 at 02:08:16PM -0400, David Banning wrote:
Here is a summary;
original 3G tar file; untars fine
gzip; corrupts
bzip2; currupts
compress; corrupts
rzip; corrupts
I haven't been paying 100% attention. Just how does it fail? What do you
mean by corrupt?
Does the process
I haven't been paying 100% attention. Just how does it fail? What do you
mean by corrupt?
Does the process run to completion?
All programs zip with no errors. On reading;
root# bzip2 -t zippedfile.bz2
bzip2: 3s1.com-smartstage_ftp-full-20070502-0125AM.1b.tar.bz2:
data integrity (CRC) error
Hello David,
Wednesday, May 2, 2007, 8:46:56 AM, you wrote:
On Tue, May 01, 2007 at 11:53:55PM -0400, Kris Kennaway wrote:
On Tue, May 01, 2007 at 11:22:28PM -0400, David Banning wrote:
Another piece of info - I just complied rzip and it seems I
have the same problem there! There must be
Can't it be that zip just don't have enough space for temporary storage?
Hi Igor. Thanks for the input. While gzipping and gunziping I
watched those directories and they don't change. The new file
is being created in the target directory - when it completes
it deletes the old file in the same
On Tue, May 01, 2007 at 03:58:26PM -0400, David Banning wrote:
I am attempting to zip large files that are 2GB - 3GB.
uname -a;
FreeBSD 3s1.com 4.11-STABLE FreeBSD 4.11-STABLE #7
I have tried gzip, bzip2 from the ports and rzip.
OK, none of those are zip though :) They're completely
On Tue 01 May 2007 16:05, Kris Kennaway wrote:
On Tue, May 01, 2007 at 03:58:26PM -0400, David Banning wrote:
I am attempting to zip large files that are 2GB - 3GB.
uname -a;
FreeBSD 3s1.com 4.11-STABLE FreeBSD 4.11-STABLE #7
I have tried gzip, bzip2 from the ports and rzip.
David Banning wrote:
I am attempting to zip large files that are 2GB - 3GB.
uname -a;
FreeBSD 3s1.com 4.11-STABLE FreeBSD 4.11-STABLE #7
I have tried gzip, bzip2 from the ports and rzip.
All give no errors on zipping, but will not unzip, siting
CRC errors.
Is there a maximum file size for
Maybe a file or library that all zip programs depend on that is
corrupt?
Your system is not too old, there were plenty of big files around when
4.11 was released. Sometimes we had to refill the oil lamps before gzip
completed, but we made do.
You are right about the age of the system - I
Another piece of info - I just complied rzip and it seems I
have the same problem there! There must be something in common,
that these programs are using...
___
freebsd-questions@freebsd.org mailing list
On Tue, May 01, 2007 at 11:22:28PM -0400, David Banning wrote:
Another piece of info - I just complied rzip and it seems I
have the same problem there! There must be something in common,
that these programs are using...
Is your filesystem full? :)
Kris
On Tue, May 01, 2007 at 11:53:55PM -0400, Kris Kennaway wrote:
On Tue, May 01, 2007 at 11:22:28PM -0400, David Banning wrote:
Another piece of info - I just complied rzip and it seems I
have the same problem there! There must be something in common,
that these programs are using...
Is
30 matches
Mail list logo
