Dave Korn wrote: > It's still odd that cygcheck (which is an all-win32-native program) > would report false results like that.
I updated Cygwin just now. The problem still exists. Attached please find
the output of:
2006-05-29 16:44:48 [EMAIL PROTECTED] /backup/p42800e
$ cygcheck -s -v -r > cygcheck-20060529-1644.out
It's interesting to note that gzip works fine on small files
(cygcheck-20060529-1644.out, 16 kB), but barfs on big ones
(p42800e-exchange-20060527-230000.bkf, 505,973 MB):
2006-05-29 16:48:01 [EMAIL PROTECTED] /backup/bin/p42800e
$ ./run-gzips
===== Mon May 29 16:48:06 2006 run-gzips begin =====
/usr/local/bin/gzips /backup/p42800e
/usr/bin/gzip '/cygdrive/e/backup/p42800e/cygcheck-20060529-1644.out'
/usr/bin/gzip
'/cygdrive/e/backup/p42800e/p42800e-exchange-20060527-230000.bkf'
gzip:
/cygdrive/e/backup/p42800e/p42800e-exchange-20060527-230000.bkf.gz: No space
left on device
/usr/local/bin/gzips: system() call failed: 256 at /usr/local/bin/gzips
line 56.
./run-gzips: system() call failed: 256 at ./run-gzips line 16.
David
cygcheck-20060529-1644.out
Description: Binary data
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
