Zitat von Phil Stracchino :
> On 08/22/12 11:18, lst_ho...@kwsoft.de wrote:
>> Zitat von lst_ho...@kwsoft.de:
>>> according to the manual client based software compression is not
>>> useful when using tape drives with builtin compression like LTO. Is
>>> this still true when using data encryption
On 08/22/12 11:18, lst_ho...@kwsoft.de wrote:
> Zitat von lst_ho...@kwsoft.de:
>> according to the manual client based software compression is not
>> useful when using tape drives with builtin compression like LTO. Is
>> this still true when using data encryption? With this the encrypted
>> data ar
Zitat von lst_ho...@kwsoft.de:
> Hello
>
> according to the manual client based software compression is not
> useful when using tape drives with builtin compression like LTO. Is
> this still true when using data encryption? With this the encrypted
> data are normally not really compresable anymor
Hello
according to the manual client based software compression is not
useful when using tape drives with builtin compression like LTO. Is
this still true when using data encryption? With this the encrypted
data are normally not really compresable anymore but a compression on
the client be
PROTECTED]; 'Landon Fuller';
bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] Encryption/Compression Conflict in CVS
> Landon,
>
> I've changed the code so that the encryption code prefixes the data block
> with a block length prior to encryption.
>
>
that is also used
for sparse file length.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Landon
> Fuller
> Sent: Wednesday, November 01, 2006 7:08 PM
> To: Michael Brennen
> Cc: bacula-users@lists.sourceforge.net
> Subje
On Nov 1, 2006, at 23:25, Michael Brennen wrote:
On Wed, 1 Nov 2006, Robert Nelson wrote:
On top of the issue with the reversed processing during restore
that I
previously mentioned, there is a fundamental flaw in the
processing of
compressed+gzipped data. The problem is that boundaries a
On Nov 2, 2006, at 13:22, Robert Nelson wrote:
The problem is that currently there are three filters defined:
compression,
encryption, and sparse file handling. The current implementation of
compression and sparse file handling both require block boundary
preservation. Even if zlib streamin
On Nov 2, 2006, at 08:30, Robert Nelson wrote:
Landon,
I've changed the code so that the encryption code prefixes the data
block
with a block length prior to encryption.
The decryption code accumulates data until a full data block is
decrypted
before passing it along to the decompressio
eforge.net
Subject: Re: [Bacula-users] Encryption/Compression Conflict in CVS
On Nov 2, 2006, at 13:22, Robert Nelson wrote:
> The problem is that currently there are three filters defined:
> compression,
> encryption, and sparse file handling. The current implementation of
> compr
explore a whole section of the
Bacula code I hadn't played with before. :-).
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Landon
Fuller
Sent: Wednesday, November 01, 2006 7:08 PM
To: Michael Brennen
Cc: bacula-users@lists.sourceforge.net
Subjec
Hi,
On 11/2/2006 12:20 PM, Alan Brown wrote:
> On Wed, 1 Nov 2006, Arno Lehmann wrote:
>
>
>>>Not if compression happens prior to encryption. :)
>>
>>Theoretically - yes, but I'm quite sure that encryption usually also
>>compresses data.
>
>
> If the encryption routines also contain compressio
file handling would be broken.
-Original Message-
From: Landon Fuller [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 02, 2006 11:06 AM
To: Robert Nelson
Cc: 'Michael Brennen'; [EMAIL PROTECTED];
bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] Encryption/C
On Thursday 02 November 2006 10:30, Robert Nelson wrote:
> The code now works for all four scenarios with encryption and compression:
> none, encryption, compression, and encryption + compression. Unfortunately
> the code is no longer compatible for previously encrypted backups.
Excellent. Is t
app itself)?
-Original Message-
From: Robert Nelson <[EMAIL PROTECTED]>
Subj: Re: [Bacula-users] Encryption/Compression Conflict in CVS
Date: Thu Nov 2, 2006 11:30 am
Size: 2K
To: 'Landon Fuller' <[EMAIL PROTECTED]>, 'Michael Brennen' <[EMAIL PRO
eforge.net
Subject: Re: [Bacula-users] Encryption/Compression Conflict in CVS
On Nov 1, 2006, at 2:20 PM, Michael Brennen wrote:
> On Wednesday 01 November 2006 15:33, Arno Lehmann wrote:
>
>>>> This sounds like compression should be automatically disabled when
>>>> encryp
On Wed, 1 Nov 2006, Arno Lehmann wrote:
>> Not if compression happens prior to encryption. :)
>
> Theoretically - yes, but I'm quite sure that encryption usually also
> compresses data.
If the encryption routines also contain compression routines.
> This is completely unverified and refers to en
On Wed, 1 Nov 2006, Robert Nelson wrote:
> On top of the issue with the reversed processing during restore that I
> previously mentioned, there is a fundamental flaw in the processing of
> compressed+gzipped data. The problem is that boundaries aren't preserved
> across encrypt/decrypt.
>
> What
ailto:[EMAIL PROTECTED] On Behalf Of Landon
Fuller
Sent: Wednesday, November 01, 2006 7:08 PM
To: Michael Brennen
Cc: bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] Encryption/Compression Conflict in CVS
On Nov 1, 2006, at 2:20 PM, Michael Brennen wrote:
> On Wednesday 01 Novem
On Nov 1, 2006, at 2:20 PM, Michael Brennen wrote:
On Wednesday 01 November 2006 15:33, Arno Lehmann wrote:
This sounds like compression should be automatically disabled when
encrypton is enabled. Should be useless anyway as encrypted data
should
no longer be compressible.
Not if compres
On Wed, 1 Nov 2006, Landon Fuller wrote:
>> Landon, what is your take on this? Since you wrote the code you
>> seem to be the best source on whether the openssl functions you
>> are using compress data.
>
> The encryption does not include compression -- It made more sense
> to piggyback on the
On Wednesday 01 November 2006 15:33, Arno Lehmann wrote:
> >>This sounds like compression should be automatically disabled when
> >>encrypton is enabled. Should be useless anyway as encrypted data should
> >>no longer be compressible.
> >
> > Not if compression happens prior to encryption. :)
>
>
Hi,
On 11/1/2006 6:00 PM, Michael Brennen wrote:
> On Wednesday 01 November 2006 05:43, Arno Lehmann wrote:
>
>
>>>So... in my testing the combination of encryption and compression is
>>>either not writing files correctly to tape (in which case there is a
>>>lot of tape space taken up needlessly
ednesday, November 01, 2006 3:43 AM
> To: bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Encryption/Compression Conflict in CVS
>
> Hi,
>
> On 11/1/2006 5:43 AM, Michael Brennen wrote:
> > I posted a couple of days ago that restoring files from 1.39
On Wednesday 01 November 2006 05:43, Arno Lehmann wrote:
> > So... in my testing the combination of encryption and compression is
> > either not writing files correctly to tape (in which case there is a
> > lot of tape space taken up needlessly :) or the files are being
> > corrupted in the restor
PROTECTED] On Behalf Of Arno
Lehmann
Sent: Wednesday, November 01, 2006 3:43 AM
To: bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] Encryption/Compression Conflict in CVS
Hi,
On 11/1/2006 5:43 AM, Michael Brennen wrote:
> I posted a couple of days ago that restoring files from 1.3
Hi,
On 11/1/2006 5:43 AM, Michael Brennen wrote:
> I posted a couple of days ago that restoring files from 1.39.27
> (current CVS) with both encryption and compression turned on
> resulted in 0 length files being restored.
>
> I was able to test that further tonight by archiving and restoring a
I posted a couple of days ago that restoring files from 1.39.27
(current CVS) with both encryption and compression turned on
resulted in 0 length files being restored.
I was able to test that further tonight by archiving and restoring a
file in the 4 combinations of encryption/compression off/
28 matches
Mail list logo
