>>>> "BAW" == Barry Warsaw
BAW> Anyway, through quite a bit of testing what appears to be
BAW> happening is that \r's in the original encrypted text are
BAW> getting converted to \n's when read from call-process. It's
BAW> also possible that they will get converted when written back
BAW> out to file. This happens even when the buffer's coding is
BAW> 'binary, and it's obvious to see how this will corrupt the
BAW> saved encrypted file.
BAW> My fix for this is in crypt.el's crypt-write-file-hook
BAW> function. I'm sorry I don't have a diff, but the fix is
BAW> fairly simple. OTOH, I'm not sure it's the /right/ fix. In
BAW> any event, in the let (see ;; BINDINGS) at about line 1689
BAW> which encloses the calls to crypt-encrypt-buffer and
BAW> write-region, I've added these bindings:
BAW> (coding-system-for-read 'binary)
BAW> (coding-system-for-write 'binary)
I don't use crypt, so I can't say for sure, but your theory is right
and this is the theoretically correct fix.
I'll fiddle with it a bit, but the main thing that would hold up a
package release IMO is writing a test suite.
It's a bit of a kludge, but I think what can be done is to add a file
to the *core* test
It appears that both are necessary. With this fix I can read and
write encrypted files again! :)
I believe I'm using the latest crypt.el from os-utils 1.37 (crypt.el
says 2.83 at the top). Please let me know if you think a better fix
is in order. I'll be happy to test anything to get this fixed in the
next package release.
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.