With pkg-config missing, a broken configure was generated, that failed
with a confusing error:
./configure: line 19272: syntax error near unexpected token `OPENSSL,'
./configure: line 19272: ` PKG_CHECK_MODULES(OPENSSL, openssl >= 0.9.7,'
Now, it errors out in the autoconf stage with:
configure.ac:23: error: possibly undefined macro: PKG_CHECK_MODULES
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
one search twice (one for adding the path of the library to LDFLAGS and
the other for eventually checking that the library is actually added)
for the same symbol (fuse_new) that resuls in the configure script
caching the first result of the test (which is 'false' because the
library where not still added) and reuseing it in the second test. A
solution is to use two different symbols for theses two tests).
This removes the need for a translated prompt. Fixes issue #20.
Also,
* merge boolDefaultNo() and boolDefaultYes() into boolDefault()
* do not accept arbitrary answers, but prompt again
Example Results
* Seagate Barracuda 7200.9, model ST3250824AS
* Linux 3.16.3
* EncFS 1c5c75c44f
Test | EncFS | eCryptfs | EncFS advantage
----------------|--------------|--------------|----------------
stream_write | 32 MiB/s | 38 MiB/s | 0.84
extract | 28744 ms | 30027 ms | 1.04
du | 495 MB | 784 MB | 1.58
rsync | 3319 ms | 62486 ms | 18.83
delete | 6462 ms | 74652 ms | 11.55
(eCryptfs is very slow for stat() on a classical HDD)
This prevents unexpected failures when you have set that variable.
Also, give Test::More the number of tests that will be run for
more informative output.
In reverse mode, this caused symlinks pointing to the absolute
plaintext directory to be stripped. This is what the test in
commit
tests: reverse: symlink absolute path inside the plaintext dir
checks for.
Ignoring encfsctl, plainPath() is only called from encfs.cpp, in
_do_readlink() and _do_getattr(). Both functions get the path passed in from
FUSE. Paths from FUSE are always anchored at the mountpoint (they start with
"/", and "/" means the root of the mount). This suggests that the check can
never trigger - I have verified that it does not trigger when running the
test suite.
With this patch, the full test suite passes.
Writing to the ciphertext files can rewrite the header. This
would mean we had to re-encrypt the whole file with the new IV.
This could be made more fine-grained, for example allowing
writes to everywhere but the header. However, this is
something that needs a lot of testing to ensure correctness.
Writing to the ciphertext is a niche use case of the niche
use case of using reverse mode, so it is unlikely it would
get the test coverage it needs.
To be safe, we deny all modifications of the ciphertext with
read-only filesystem error (EROFS) if uniqueIV is enabled.
Reverse mode with uniqueIV disabled still supports writing,
if somebody really needs it. This use case is not covered
by the test suite at the moment.
