[PATCH] Don't seek to the end when opening files with APR_FOPEN_APPEND

[Evgeny Kotkov <ev...@visualsvn.com>]

Hi everyone,

Currently, the Windows implementation of APR_FOPEN_APPEND flag performs
a seek to the file's end when opening it.

Apparently, this is a leftover from the very first version of handling file
appends (https://svn.apache.org/r59449) that performed a single seek to
the file's end when opening it and did not support proper atomic appends
with multiple process or threads writing to the same file.

Since then, such atomic appends have been implemented, but the seek
was not removed.  It can cause unexpected behavior when reading from
a file opened with APR_FOPEN_APPEND, assuming no writes happened
to the file.  In this case, as there have been no writes, the file offset
should not be repositioned and reading should start from the beginning of
the file.  However, due to the unwanted seek during open, the actual reading
would instead start from the file's end and cause an unexpected EOF.

The attached patch fixes the issue and adds a test for it.  The log message
is included in the beginning of the patch file.


Thanks,
Evgeny Kotkov

Re: [PATCH] Don't seek to the end when opening files with APR_FOPEN_APPEND

[Evgeny Kotkov <ev...@visualsvn.com>]

Evgeny Kotkov <ev...@visualsvn.com> writes:

> Currently, the Windows implementation of APR_FOPEN_APPEND flag performs
> a seek to the file's end when opening it.
>
> Apparently, this is a leftover from the very first version of handling file
> appends (https://svn.apache.org/r59449) that performed a single seek to
> the file's end when opening it and did not support proper atomic appends
> with multiple process or threads writing to the same file.
>
> Since then, such atomic appends have been implemented, but the seek
> was not removed.  It can cause unexpected behavior when reading from
> a file opened with APR_FOPEN_APPEND, assuming no writes happened
> to the file.  In this case, as there have been no writes, the file offset
> should not be repositioned and reading should start from the beginning of
> the file.  However, due to the unwanted seek during open, the actual reading
> would instead start from the file's end and cause an unexpected EOF.
>
> The attached patch fixes the issue and adds a test for it.  The log message
> is included in the beginning of the patch file.

Committed in https://svn.apache.org/r1808456


Regards,
Evgeny Kotkov