2010/7/28 Sergio Belkin sebelk@gmail.com:
2010/7/28 Stephen Harris lists@spuddy.org:
DFILE_OFFSET_BITS=64
I have installed both 32 and 64 bit versions of openssl, can that be the cause of this problem?
Thanks in advance
--
My fault, indeed, somewhat large files is a relative term, for example it can't decrypt files
You can read full ouput on: http://pastebin.com/7yZeGEa4
I've tried using both
"openssl bf -d -in $1 -out $FILE -k $KEY" and "cat $1 | openssl bf -debug -d -out $FILE -k $KEY > $1.unc"
and failed either.
For encrypting I use:
# esta funcion reemplaza a guardapgsql, guardaldap, y guardamysql guardadump() { logstr "guardando $1-dump con blowfish" ARCH=$1.dump.all.$DATE.gz.bf case $1 in mysql) CMD='mysqldump -Q -l -F --add-locks --add-drop-table -A';; ldap) CMD='slapcat -c ';; pgsql) CMD='sudo -u postgres pg_dumpall -v -c';; esac $CMD | compress | openssl bf -out $ARCH -k "$key" 2>> $LOGFILE return $? }
(Of course it's only a part of a file)
I started to think that size is not the problem, for example I have files:
-rw-r--r-- 1 root root 10264 Jul 29 00:24 usr.local.etc.Thu-29-Jul-2010.tgz.bf -rw-r--r-- 1 root root 4402600 Jul 29 00:23 dir.Thu-29-Jul-2010.gz -rw-r--r-- 1 root root 4853784 Jul 29 00:24 usr.lib.perl5.5.8.8.UP.Thu-29-Jul-2010.tgz.bf -rw-r--r-- 1 root root 12554264 Jul 29 00:24 etc.Thu-29-Jul-2010.tgz.bf -rw-r--r-- 1 root root 17302224 Jul 29 00:23 ldap.dump.all.Thu-29-Jul-2010.gz.bf -rw-r--r-- 1 root root 92241944 Jul 29 00:24 scripts.Thu-29-Jul-2010.tgz.bf -rw-r--r-- 1 root root 209591864 Jul 29 00:23 pgsql.dump.all.Thu-29-Jul-2010.gz.bf
And scripts.Thu-29-Jul-2010.tgz.bf can be decrypted. May compress the "culprit"? I tried with a small database (544 K compressed with ncompress) and have no problem anyway, so I am rather puzzled :(
Any idea?
TIA