Revert r1808456 (Win32: Don't seek to the end when opening files with

APR_FOPEN_APPEND).

While this change fixed an issue where Windows and Unix reported different
offsets after opening files for append, it also caused a regression: for
files opened with APR_FOPEN_APPEND | APR_FOPEN_BUFFERED, flushing their
contents would cause the contents to be written at offset 0, rather than
appended.

This happens because flushes and regular writes use different code paths.
And while regular writes guarantee that an append will happen to the end of
the file, a buffer flush uses a regular WriteFile(), assuming the file pointer
has been properly set before.

To fix both issues, we'd probably need to rework this part and make all
writes use the same approach.  But for now let's revert this change to fix
the regression, that was also reported in [1].

I'll add a regression test for this problem separately.

[1] https://lists.apache.org/thread/56gnyc3tc0orjh5mfsqo9gpq1br59b01

git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1909088 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 1 insertions, 0 deletions

diff --git a/file_io/win32/open.c b/file_io/win32/open.c
index 8249c6cea..50d27508d 100644
--- a/file_io/win32/open.c
+++ b/file_io/win32/open.c
@@ -369,6 +369,7 @@ APR_DECLARE(apr_status_t) apr_file_open(apr_file_t **new, const char *fname,
 
     if (flag & APR_FOPEN_APPEND) {
         (*new)->append = 1;
+        SetFilePointer((*new)->filehand, 0, NULL, FILE_END);
     }
     if (flag & APR_FOPEN_BUFFERED) {
         (*new)->buffered = 1;