On Mon, May 11, 2009 at 2:06 PM, Babak Farhang wrote:
> I am not familiar with the details of CFS, but I didn't interpret
> Michael's comment to mean that there is actually any rewriting going
> on here. The problem here appears to be one of translating the
> encrypted/compressed file position to
On Mon, May 11, 2009 at 12:19 AM, Andrzej Bialecki wrote:
>
> Unfortunately, current Lucene IndexWriter implementation uses seek /
> overwrite when writing term info dictionary. This is described in more
> detail here:
>
> https://issues.apache.org/jira/browse/LUCENE-532
>
Thanks for the enlight
Babak Farhang wrote:
If "position" is the only thing Lucene needs during writing, then that
is good news: seeking backwards and overwriting what's already
written--that would be difficult to implement. If Lucene employs a
write once strategy for file I/O (w/ no exceptions), then we wont
really
terested in storing data from a database in the index, at
>> > times I want to encrypt the index when the file is one disk.
>> >
>> > Currently data stored in the Lucene Index is easily accessible to any
>> > program that wants to access it. You cannot store sensitive
pplications the price of having unsecure data is
>> unacceptable, when secure data is published to a laptop for use
offline.
>> In this case, the additional time needed to access the index would be
>> acceptable.
>>
>> Examples: Military, Medical, and Financial information.
e price of having unsecure data is
>> unacceptable, when secure data is published to a laptop for use offline.
>> In this case, the additional time needed to access the index would be
>> acceptable.
>>
>> Examples: Military, Medical, and Financial information.
>&
he additional time needed to access the index would be
acceptable.
Examples: Military, Medical, and Financial information.
Thanks,
Peter
Subject:
Re: Lucene Index Encryption
<http://markmail.org/message/2munvfksg4gvifek>
Actions...
From:
Michael McCandless (luc...@mikemccandless.com)
Dat
ndex is easily accessible to any
program that wants to access it. You cannot store sensitive data in the
index without the fear that it will be readable by all the people that
have access to the system.
There are two other posts in the mailing list that ask a question about
Lucene Index Encryption.
s easily accessible to any
program that wants to access it. You cannot store sensitive data in the
index without the fear that it will be readable by all the people that
have access to the system.
There are two other posts in the mailing list that ask a question about
Lucene Index Encryption. In
ndex is easily accessible to any
> > program that wants to access it. You cannot store sensitive data in the
> > index without the fear that it will be readable by all the people that
> > have access to the system.
> >
> > There are two other posts in the mailing list
> have access to the system.
>
> There are two other posts in the mailing list that ask a question about
> Lucene Index Encryption. In both cases, I think that the conservation
> was dropped or the feature put off.
>
> Basically, I am asking for comments on the topic. I might
ata stored in the Lucene Index is easily accessible to any
> program that wants to access it. You cannot store sensitive data in the
> index without the fear that it will be readable by all the people that
> have access to the system.
>
> There are two other posts in the mailing list t
Index Encryption. In both cases, I think that the conservation
was dropped or the feature put off.
Basically, I am asking for comments on the topic. I might consider
coding the feature, but I would only do it if I am sure that the feature
would be useful and accepted back into the core codebase of
13 matches
Mail list logo