Time preservation invalid: when the time and year of the file is 2275, the time of the destination cannot be modified

[Schofi]

code

import (
    cp "github.com/otiai10/copy"
)
opt := cp.Options{PreserveTimes: true}
    err := cp.Copy("/Volume1/souce", "/Volume1/@usb/dest/",
        opt,
    )

File system :exfat32 Create a new file in /Volume1/souce : touch -t 227506062145 top.txt Destination file time

Total inconsistency between source and destination times

[otiai10]

Windows? Please take a look at this https://github.com/otiai10/copy/blob/main/preserve_ltimes_x.go

[Schofi]

it is invalid in linux.

[otiai10]

@otiai10 Note:

[Schofi]

@otiai10 Note:

when you copy bbb.txt to another directory using "github.com/otiai10/copy" in Linux ,you will find bbb.txt time is not correct.

[otiai10]

Could you please describe what you are saying just more little bit?

1. What you did
2. What you saw
3. What you expected

[Schofi]

Could you please describe what you are saying just more little bit?

1. What you did i touch -t 227506062145 top.txt ,it time is 2262 ,copy this top.txt to anthor dir,it time will change to 15/11/1690

2. What you saw it time will change to 15/11/1690

3. What you expected it time shoulde be 2262

[otiai10]

As far as I understand, I recognize this problem as follows:

What you do

Setup

touch -t 227506062145 your-dir/top.txt

Copy

cp.Copy("your-dir", "your-copy", cp.Options{
    PreserveTimes: true,
})

Check

ls -la your-copy/top.txt

What you want

2262 08 47 16 top.txt

Year should be 2262

What you see

1690 15 11 00 top.txt

[otiai10]

     -t      Change the access and modification times to the specified time
             instead of the current time of day.  The argument is of the form
             “[[CC]YY]MMDDhhmm[.SS]” where each pair of letters represents the
             following:

                   CC      The first two digits of the year (the century).
                   YY      The second two digits of the year.  If “YY” is
                           specified, but “CC” is not, a value for “YY”
                           between 69 and 99 results in a “CC” value of 19.
                           Otherwise, a “CC” value of 20 is used.
                   MM      The month of the year, from 01 to 12.
                   DD      the day of the month, from 01 to 31.
                   hh      The hour of the day, from 00 to 23.
                   mm      The minute of the hour, from 00 to 59.
                   SS      The second of the minute, from 00 to 60.

             If the “CC” and “YY” letter pairs are not specified, the values
             default to the current year.  If the “SS” letter pair is not
             specified, the value defaults to 0.

[[CC]YY]MMDDhhmm[.SS]

• CC = 22
• YY = 75
• MM = 06
• DD = 06
• hh = 21
• mm = 45

[otiai10]

In Linux, the maximum value of ctime (inode change time) and atime (access time) is determined by the time_t data type, which is typically a signed 32-bit or 64-bit integer. This means that the maximum value will depend on whether your system uses a 32-bit or 64-bit architecture.

For a 32-bit architecture, the maximum value of time_t is 2,147,483,647, which represents the date and time Tuesday, January 19, 2038, 3:14:07 AM.

For a 64-bit architecture, the maximum value of time_t is typically 9,223,372,036,854,775,807, which represents the date and time Sunday, February 7, 2106, 6:28:15 AM.

Note that these maximum values assume that the time_t data type is represented in seconds since the epoch, which is January 1, 1970, 00:00:00 UTC.

[markusressel]

For a 64-bit architecture, the maximum value of time_t is typically 9,223,372,036,854,775,807, which represents the date and time Sunday, February 7, 2106, 6:28:15 AM.

That can't be right, where did you get this from? A 64 bit integer should be able to represent dates insanely far into the future (like in the millions of years), not just a mere 68 years.

[otiai10]

I remember that was from ChatGPT, thus I kept it as blockquote and I don't trust it as well.