| 1 |
Neil Bothwick <neil@××××××××××.uk> writes: |
| 2 |
|
| 3 |
> On Fri, 08 Jul 2011 14:35:55 -0400, Albert Hopkins wrote: |
| 4 |
> |
| 5 |
>> Having said that: |
| 6 |
>> One of encfs's Achilles heel is its dependency on the boost C++ library |
| 7 |
>> which is *very* sensitive wrt to API/ABI changes and the like. It also |
| 8 |
>> depends on OpenSSL which also shares this notoriety (although, in my |
| 9 |
>> experience, less so). So there is a possibility that an update to any |
| 10 |
>> of those packages may have broken encfs and you need to rebuild the |
| 11 |
>> package. |
| 12 |
> |
| 13 |
> Apart from the need to access legacy data, which Harry has resolved by |
| 14 |
> reformatting, is there any benefit in using encfs rather than the |
| 15 |
> in-kernel ecryptfs these days? |
| 16 |
|
| 17 |
Are you using ecryptfs? I started looking around and thinking exactly |
| 18 |
what Albert says is not a proper response, and wondering if ecryptfs |
| 19 |
might be a better choice. |
| 20 |
|
| 21 |
Also after seeing no responses or any posts at all on the encfs group, |
| 22 |
I wondered if ecryptfs is under active development, as it appears |
| 23 |
encfs is not. So, for that reason alone, (assuming there is current |
| 24 |
active devel going on with ecryptfs) it might be good to switch. |
| 25 |
|
| 26 |
I will admit though, that I have had several trouble free yrs of use |
| 27 |
with encfs.. and it appears now that my reported problems may have |
| 28 |
been largely self inflicted wounds. |
Archives