RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

David Holmes david.holmes at oracle.com
Wed Nov 21 03:53:53 UTC 2018

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 

"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:
> 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

More information about the core-libs-dev mailing list