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
Thank you @sendaoYan for running this experiment and checking the code.
> So the system call utimes set the directory to the Unix epoch time.
That answers one part of my question - so it's not the JDK code which is
(re)setting the timestamp to Unix Epoch. That's a good thing. The other part to
the question was whether the underlying filesystem always sets it to exact Unix
epoch and from what I understand of your experiments, it always sets it to this
value.
Given this, the change in this PR looks good to me. I'll run this change in our
CI just to be sure that it doesn't cause any unexpected issues there.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28367#issuecomment-3579380186
