RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32
david.holmes at oracle.com
Wed Nov 21 03:53:53 UTC 2018
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
"Entire JDK should be built with -D_FILE_OFFSET_BITS=64"
then we had the long standing:
"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:
"UL: File size limit on 32 bit Linux"
"SecureDirectoryStream doesn't work on linux non-x86"
"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.
On 21/11/2018 12:46 pm, Nick Gasson wrote:
> Can someone please help me review this small makefile patch to
> fix an issue with java.io.File::setLastModified on 32-bit
> 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.
More information about the core-libs-dev