Hi Nick,
I'll leave it for core-libs and build folk to review this, but just for
some background ... This is a bit of a recurring issue. We have the all
encompassing:
https://bugs.openjdk.java.net/browse/JDK-8165620
"Entire JDK should be built with -D_FILE_OFFSET_BITS=64"
then we had the long standing:
https://bugs.openjdk.java.net/browse/JDK-8062658
"Use of 32-bit stat on 64-bit filesystems"
which was closed as "Will not fix" due to no one owning support for
32-bit systems at the time.
Then we have spot fixes like:
https://bugs.openjdk.java.net/browse/JDK-8156181
"UL: File size limit on 32 bit Linux"
https://bugs.openjdk.java.net/browse/JDK-8165643
"SecureDirectoryStream doesn't work on linux non-x86"
https://bugs.openjdk.java.net/browse/JDK-7122222
"GC log is limited to 2G for 32-bit"
So I guess another spot fix is not unacceptable, but it might be worth
considering picking up the gauntlet for JDK-8165620 and fixing this
across the board once and for all.
Cheers,
David
On 21/11/2018 12:46 pm, Nick Gasson wrote:
Hi,
Can someone please help me review this small makefile patch to
fix an issue with java.io.File::setLastModified on 32-bit
systems?
https://bugs.openjdk.java.net/browse/JDK-8214077
http://cr.openjdk.java.net/~njian/8214077/webrev.0/
If the file size is > 2GB so that the size won't fit in a signed
32-bit off_t all stat() calls will fail with EOVERFLOW. This causes
the native method UnixFileSystem::setLastModifiedTime to fail as it
uses stat() to preserve the access time. It also causes other methods
like File::length and File::lastModified to return 0.
Fix by defining _FILE_OFFSET_BITS=64 when building
UnixFileSystem_md.c, this will make off_t 64 bits.
Found on ARM32 but I believe this affects 32-bit x86 too. Checked for
no new Jtreg regressions with this patch.
Thanks,
Nick
