summaryrefslogtreecommitdiff
path: root/STATUS
diff options
context:
space:
mode:
authorkotkov <kotkov@13f79535-47bb-0310-9956-ffa450edef68>2023-04-12 12:51:03 +0000
committerkotkov <kotkov@13f79535-47bb-0310-9956-ffa450edef68>2023-04-12 12:51:03 +0000
commit4eebf5326cb670cf68ce39a0ee81c24793f96861 (patch)
tree2e0647ab3f35bd2967641df6f4aa5513d7e30bd6 /STATUS
parentcdfa0b0305f3dc1bb811fe68e0bbfb7601f3307d (diff)
downloadlibapr-4eebf5326cb670cf68ce39a0ee81c24793f96861.tar.gz
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
Diffstat (limited to 'STATUS')
0 files changed, 0 insertions, 0 deletions