ITAGAKI Takahiro wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
>>> We probably need to add PG_BINARY when we open control files
>>> because 0x1A is an end-of-file marker on Windows.
>> Well, why is that a bug? If the platform is so silly as to define text
>> files that way, who are we to argue?
>
> Google says it is for for backward compatibility with CP/M
> http://en.wikipedia.org/wiki/End-of-file
> and adding O_BINARY is the answer.
> http://codenewbie.com/forum/standard-c-c/1208-binary-i-o-file-reading-0x1a-trouble.html
Yes, apparently that's exactly why we have PG_BINARY, see c.h:
> /*
> * NOTE: this is also used for opening text files.
> * WIN32 treats Control-Z as EOF in files opened in text mode.
> * Therefore, we open files in binary mode on Win32 so we can read
> * literal control-Z. The other affect is that we see CRLF, but
> * that is OK because we can already handle those cleanly.
> */
> #if defined(WIN32) || defined(__CYGWIN__)
> #define PG_BINARY O_BINARY
> #define PG_BINARY_A "ab"
> #define PG_BINARY_R "rb"
> #define PG_BINARY_W "wb"
> #else
> #define PG_BINARY 0
> #define PG_BINARY_A "a"
> #define PG_BINARY_R "r"
> #define PG_BINARY_W "w"
> #endif
I don't see anything wrong with the patch, but I wonder if there's more
open() calls that need the same treatment? Like the one in
pg_resetxlog.c/ReadControlFile().
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com