On 31/01/2017 19:43, .. ink .. wrote:
Greetings,i am a current maintainer of a project called
"SiriKali"[1][4] and it is also affected[2] by this bug in encfs.
encfs upstream has said that this "new" behavior of encfs is a bug
that needs to be fixed[3]. Why not fix this
buggy encfs behavior and let cryptkeeper among other front ends to
encfs continue to work as expected?
This bug is not in cryptkeeper,its in encfs and continuing with this
buggy behavior of encfs will break a lot more
projects than SiriKali and cryptkeeper and will cause encfs in debian
to behave differently from everybody else when
upstream release a new version that does not have this behavior.
I think cryptkeeper should be left alone and focus be redirected to
the change in encfs behavior that upstream now
disagrees with that started all this.
[1] https://mhogomchungu.github.io/sirikali/
[2]
https://github.com/tomm/cryptkeeper/issues/23#issuecomment-276288921
[3]
https://github.com/tomm/cryptkeeper/issues/23#issuecomment-276304206
[4] https://packages.debian.org/sid/sirikali
Hello,
thanks for the comment.
Maybe a better solution could be to check output of encfs before piping
anything,
or maybe, we can do a mount result check to see if all worked fine; but
we can't
send "p" command trusting that encfs is waiting for a choice between "p"
and "x".
This is my humble opinion.
Cheers,
Francesco
