On Sat, 22 Nov 2025 13:25:01 GMT, SendaoYan <[email protected]> wrote:
>> Hi all,
>>
>> Test tools/jar/ReproducibleJar.java fails when running on a file system that
>> only supports to 2038(e.g. XFS).
>>
>> Before this PR, test check if the input test time after
>> "2038-01-19T03:14:07Z" and the extracted time created by jar is equal to
>> "2038-01-19T03:14:07Z", then test will skip that check.
>>
>> But the extraced time created by jar equal to "1970-01-01T00:00:00Z"
>> actually. I think the extracted time set to unix epoch time is acceptable,
>> so this PR fix the test make test check skip when the extracted time is unix
>> epoch time.
>>
>> Change has been verified locally on XFS file system and ext4 file system.
>
> I create a demo to explain what utimes linux system call works on XFS file
> system.
>
> When the time value bigger or equals the maximum of signed integer, then the
> time will set to UNIX epoch time.
>
>
> #include <stdio.h>
> #include <sys/time.h>
> #include <time.h>
> #include <stdlib.h>
>
> int main(int argc, char** argv) {
> if (argc != 3) {
> printf("usage: ./a.out file seconds\n");
> return 1;
> }
> const char *filename = argv[1];
> struct timeval times[2];
> long time = atol(argv[2]);
>
> times[0].tv_sec = time; // atime
> times[0].tv_usec = 0;
>
> times[1].tv_sec = time; // mtime
> times[1].tv_usec = 0;
>
> int ret = utimes(filename, times);
> printf("utimes to file %s as %ld return code is %d\n", filename, time,
> ret);
>
> return 0;
> }
>
>
> Test command and result:
>
>
>> gcc -Wall -Wextra ~/compiler-test/zzkk/utimes-test.c ; ./a.out a.out
>> 2147483646 ; stat --format %y a.out
> utimes to file a.out as 2147483646 return code is 0
> 2038-01-19 11:14:06.000000000 +0800
>> gcc -Wall -Wextra ~/compiler-test/zzkk/utimes-test.c ; ./a.out a.out
>> 2147483647 ; stat --format %y a.out
> utimes to file a.out as 2147483647 return code is 0
> 1970-01-01 08:00:00.000000000 +0800
Hello @sendaoYan, do you plan to integrate this before the rampdown fork today?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28367#issuecomment-3610610847
