[RFC] 4950302: (fs spec) Random write produces different results on Linux vs Windows from same .class

[Brian Burkhalter]

This issue [1] is caused by a Linux bug documented in the pwrite(2) man page [2]:

        POSIX requires that opening a file with the O_APPEND flag should have 
        no effect on the location at which pwrite() writes data. However, on 
        Linux, if a file is opened with O_APPEND, pwrite() appends data to the 
        end of the file, regardless of the value of offset.

One possible fix is [3] where if O_APPEND is set, it is unset to make the pwrite() call and then reset. This of course could be problematic if another thread were writing to the same file descriptor simultaneously: not all uses of IOUtil.write() use exclusion locks. But maybe this is better than the current situation? It was verified to fix the problem shown by the reproducer included in the issue description.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-4950302
[2] https://linux.die.net/man/2/pwrite
[3] 

--- a/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c
+++ b/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c
@@ -121,6 +121,19 @@
     jint fd = fdval(env, fdo);
     void *buf = (void *)jlong_to_ptr(address);
 
+#if defined(__linux__)
+    // If file descriptor is in append mode then a positional write will
+    // actually append to the file. Temporarily suppress append mode so
+    // the write will occur at the requested position.
+    int flags = fcntl(fd, F_GETFL);
+    if (flags != -1 && flags & O_APPEND) {
+        if (fcntl(fd, F_SETFL, flags & ~O_APPEND) != -1) {
+            int result = pwrite64(fd, buf, len, offset);
+            fcntl(fd, F_SETFL, flags);
+            return convertReturnVal(env, result, JNI_FALSE);
+        }
+    }
+#endif
     return convertReturnVal(env, pwrite64(fd, buf, len, offset), JNI_FALSE);
 }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20191119/85a98f80/attachment-0001.html>