Photo UIDs on --attribute-fd on Windows and strange LF->CRLF conversions

Michael Schierl schierlm at
Wed Aug 3 18:39:39 CEST 2005

Hash: SHA1

(sorry for the private mail, David. I guess I have to read more mailing
lists to remember clicking the "reply to all" button...)

David Shaw schrieb:

> The problem here is twofold - first, you can't dump jpegs that way.
> You'll end up with garbage because it'll be mixed up with the key
> listings themselves.  The second problem is related to the first -
> you're dumping to stdout, and stdout on windows does textmode
> conversion by default.

Hmm. For that "I can't do it that way" it works surprisingly well :)

In all my tests it worked to read in "line-mode" and whenever there was an


line, switch to "byte-mode" and read that many bytes. Then check for
CR-LFs, compensate by reading a few more bytes, and go on reading in
"line-mode". That one worked well except in the case where the jpg ended
with a LF byte.

FWIW: I have that idea of "overloading stdout" from enigmail, which does
it exactly that way (if the output in the debugging console is not "faked").

> To make this work, you need to use a fd that isn't stdout, or
> something like "--attribute-file new.dat"

Other fds (except stderr, which has the same problem I guess, and stdin,
which is only writable) are not available from Java AFAIK (at least not
platform-independently); and when using »--attribute-file new2.dat« I
got the same CRLF mangling :(

And since one key can contain more than one JPEG image, the same problem
with finding the beginning/end of those applies as well as when getting
them out of stdout.

BTW doc bug: I cannot find anything about --attribute-file neither in
the manpage nor in src/doc/DETAILS

> Note in any case that the attribute is not a raw JPEG.  You'll get the
> attribute, which contains the JPEG.

Which is well-documented in src/doc/DETAILS. Yes, I know that, since it
"basically" works here.


Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird -

-------------- next part --------------
A non-text attachment was scrubbed...
Name: new2.dat
Type: application/octet-stream
Size: 654 bytes
Desc: not available
Url : /pipermail/attachments/20050803/a83a8495/new2.obj

More information about the Gnupg-devel mailing list