If you created a filesystem with encfs build with <boost-1.4.20 and then upgrade boost, and recompile encfs agains the new version, then encfs can no longer mount the filesystem. This problem appears to be reported upstream (for encfs). Contrary to the upstream bug report, I was able to downgrade boost, and recomple encfs and then use the filesystems. But possibly there should be some kind of warning to users. I'm not sure this is technically a bug (with Gentoo) but it could lead users to believe that they have lost data when in fact they have not.
Looks like boost broke backwards compatibility and encfs needs to follow. As long as this hasn't happened, it should depend on <dev-libs/boost-1.42.0 (make sure configure picks up the right boost version, see bug 297694)
Someone filed a bug on the boost bug tracker [1]. Let's see what comes out there. [1] https://svn.boost.org/trac/boost/ticket/3990
http://code.google.com/p/encfs/issues/detail?id=60 This is severe bug, which may lead to full data loss. encfs must depends on <boost-1.42 for now. encfs compiled with boost-1.42 is absolutely unusable even with newly created file systems.
There is a patch available since yesterday: http://code.google.com/p/encfs/source/detail?r=55
Created attachment 236037 [details] ebuild for encfs 1.6 I had the same problem after a new system install. Just use encfs 1.6, which fixes the problem; see my attached ebuild (derived from the 1.5 ebuild). encfs compiled and I was able to mount my encrypted directory again, using boost 1.42
Someone please bump; there are several bugs open for encfs < 1.6.
encfs-1.6 in portage, builds fine here with forced asneeded, gcc-4.5.0, and boost-1.42.0-r1.
