Filedate

Johan52

I want to copy files from my Win10 computer to my NAS540. De dates on those files are sometimes before 1/1/1970. E. 23.02.1924. It are digital copies of very old pictures. However, the NAS does not accept those dates.
How can I make the NAS accept those filedates?

Mijzelf

That's an intriguing question! First, in Linux (your NAS runs Linux) in ext4 a file has 4 timestamps, atime, mtime, ctime and btime. Access- modify- change- and birth time. Access is about last time read (which is nowadays by default hardly updated anymore, to save write cycles). Modify is about modification of the file, while Change is about modification of the inode, which keeps the metadata. So when you change ownership, the ctime is changed, but mtime is not. But if you change the file, both mtime and ctime change. Ctime changes because mtime changes, which is a metadata change. Birth is the time a file is added to the filesystem.
The timestamp we are talking about here is probably mtime.
The NAS uses ext4 for filesystem of the data partitions. Ext3 and older used a 32 bit signed timestamp in seconds, UNIX time, where '0' is 1 January 1970, 00:00:00 UTC. The 32 bits signed gives a range from 14 December 1901 to 18 January 2038. On ext4 the 32 bits stamp is used unsigned, which changes the range to 1 January 1970 to 7 February 2106. On top of that an extra 32 bits is added in a new header. 30 bits of that is used to give the stamps a nanosecond resolution, while the 2 remaining bits are used to extend the seconds range to 34 bits, yielding a range from 14 December 1901 to 10 May 2446.
So your 1924 timestamps should fit.

I mounted a share of my 520 on my Linux laptop, on ~/remote/ using cifs. Then I created a file in ~/local/ and copied that to ~/remote/

~$ touch ~/local/file.txt
~$ cp -a ~/local/file.txt ~/remote/
~$ stat ~/local/file.txt
  File: ~/local/file.txt
  Size: 0             Blocks: 0          IO Block: 4096   regular empty file
Device: 806h/2054d    Inode: 2113166     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 2021-05-09 12:23:39.186603150 +0200
Modify: 2021-05-09 12:23:39.186603150 +0200
Change: 2021-05-09 12:23:39.186603150 +0200
 Birth: 2021-05-09 12:23:39.186603150 +0200
~$ stat ~/remote/file.txt
  File: ~/remote/file.txt
  Size: 0             Blocks: 0          IO Block: 1048576 regular empty file
Device: 32h/50d    Inode: 57671683    Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 2021-05-09 12:23:39.186603100 +0200
Modify: 2021-05-09 12:23:39.186603100 +0200
Change: 2021-05-09 12:23:39.186603100 +0200
 Birth: 2021-05-09 12:24:17.060181000 +0200

As you can see all timestamps are copied, except Birth, which is to be expected as the file was new in the target filesystem. Yet the resolution is different. Windows uses a 100 nanoseconds resultion, and I think Samba follows that.. When I touch the file and copy it again, the result is

~$ touch ~/local/file.txt
~$ cp -a ~/local/file.txt ~/remote/
cp: overwrite '~/remote/file.txt'? y
~$ stat ~/local/file.txt
  File: ~/local/file.txt
  Size: 0             Blocks: 0          IO Block: 4096   regular empty file
Device: 806h/2054d    Inode: 2113166     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 2021-05-09 12:31:01.598173917 +0200
Modify: 2021-05-09 12:31:01.598173917 +0200
Change: 2021-05-09 12:31:01.598173917 +0200
 Birth: 2021-05-09 12:23:39.186603150 +0200
~$ stat ~/remote/file.txt
  File: ~/remote/file.txt
  Size: 0             Blocks: 0          IO Block: 1048576 regular empty file
Device: 32h/50d    Inode: 57671683    Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 2021-05-09 12:31:01.598173900 +0200
Modify: 2021-05-09 12:31:01.598173900 +0200
Change: 2021-05-09 12:31:01.598173900 +0200
 Birth: 2021-05-09 12:24:17.060181000 +0200

As you see the Birth time is not changed, but all 3 other stamps are transferred.

I can change the mtime and atime indepently, using touch -m and touch -a

~$ touch -m --date="1980-01-01" ~/local/file.txt
~$ touch -a --data="1990-01-01" ~/local/file.txt
~$ stat ~/local/file.txt
  File: ~/local/file.txt
  Size: 0             Blocks: 0          IO Block: 4096   regular empty file
Device: 806h/2054d    Inode: 2113166     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 1980-01-01 00:00:00.000000000 +0100
Modify: 1990-01-01 00:00:00.000000000 +0100
Change: 2021-05-09 12:43:03.028613851 +0200
 Birth: 2021-05-09 12:23:39.186603150 +0200
~$ cp -a ~/local/file.txt ~/remote/
cp: overwrite '~/remote/file.txt'? y
~$ stat ~/remote/file.txt
  File: ~/remote/file.txt
  Size: 0             Blocks: 0          IO Block: 1048576 regular empty file
Device: 32h/50d    Inode: 57671683    Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 1990-01-01 00:00:00.000000000 +0100
Modify: 1990-01-01 00:00:00.000000000 +0100
Change: 1990-01-01 00:00:00.000000000 +0100
 Birth: 2021-05-09 12:24:17.060181000 +0200

As you can see actually only the mtime is transferred. I thought. But at the other side I saw this:

admin@NAS520:/i-data/38aa86ff/music$ stat file.txt
  File: file.txt
  Size: 0             Blocks: 0          IO Block: 4096   regular empty file
Device: 902h/2306d    Inode: 57671683    Links: 1
Access: (0777/-rwxrwxrwx)  Uid: (  501/ UNKNOWN)   Gid: (  500/ UNKNOWN)
Access: 1979-12-31 23:00:00.000000000 +0000
Modify: 1989-12-31 23:00:00.000000000 +0000
Change: 2021-05-09 10:45:14.650181002 +0000
 Birth: -

So Access and Modify are both transferred to the NAS, but only Modify is transferred back. (The difference in timestamp is the due to a different time zone, and daylight saving time). Don't know why Birth is empty. When you have a local file with mtime 1990-01-01 and you copy it over, and back, it's still mtime 1990-01-01. So what about 1924?

~$ touch -m --date="1924-01-01" file.txt
~$ touch -a --date="1975-01-01" file.txt
~$ stat ~/local/file.txt
  File: ~/local/file.txt
  Size: 0             Blocks: 0          IO Block: 4096   regular empty file
Device: 806h/2054d    Inode: 2113166     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 1975-01-01 00:00:00.000000000 +0100
Modify: 1924-01-01 00:00:00.000000000 +0019
Change: 2021-05-09 13:05:51.096417288 +0200
 Birth: 2021-05-09 12:23:39.186603150 +0200
~$ cp -a ~/local/file.txt ~/remote/
cp: overwrite '~/remote/file.txt'? y
~$ stat ~/remote/file.txt
  File: ~/remote/file.txt
  Size: 0             Blocks: 0          IO Block: 1048576 regular empty file
Device: 32h/50d    Inode: 57671683    Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 2021-05-09 13:06:01.292293000 +0200
Modify: 2021-05-09 13:06:01.292293000 +0200
Change: 2021-05-09 13:06:01.292293000 +0200
 Birth: 2021-05-09 12:24:17.060181000 +0200

Samba refused to transfer 1924, and used 'now' instead. Some extra tests show that Samba doesn't transfer stamps before 1970-01-01. So it seems Samba uses a 32 bit unsigned POSIX timestamp, and an extra field containing the '100 nanoseconds'.
But there is a surprise:

~$ touch -m --date="2061-01-01" ~/local/file.txt
~$ stat ~/local/file.txt
  File: ~/local/file.txt
  Size: 0             Blocks: 0          IO Block: 4096   regular empty file
Device: 806h/2054d    Inode: 2113166     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 2021-05-09 13:13:12.189331491 +0200
Modify: 2061-01-01 00:00:00.000000000 +0100
Change: 2021-05-09 13:13:05.761389569 +0200
 Birth: 2021-05-09 12:23:39.186603150 +0200
~$ cp -a ~/local/file.txt ~/remote/
cp: overwrite '~/remote/file.txt'? y
~$ stat ~/remote/file.txt
  File: ~/remote/file.txt
  Size: 0             Blocks: 0          IO Block: 1048576 regular empty file
Device: 32h/50d    Inode: 57671683    Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 2021-05-09 13:11:35.573204500 +0200
Modify: 1924-11-25 16:51:16.000000000 +0019
Change: 1924-11-25 16:51:16.000000000 +0019
 Birth: 2021-05-09 12:24:17.060181000 +0200

So the seconds after 18 January 2038 are wrapped around, and added to 14 December 1901! There is some strange mixed signed/unsigned implementation of the timestamp. From client to server unsigned, and from server to client signed.
So here's your work around: add ~137 years to the local file's timestamp before copying them.

A more convenient way might be to store the files in an archive, for instance a zip file. Or put the timestamp in exif metadata and forget the file timestamp. Or, if you want to be able to sort the files by time in the listing, put it in the filename.

Johan52

Very extensive reply. Thanks.
I'm not a Linux guy so I don't understand everything, but I know (knew) DOS quite well so I understand the reply.
Probably the best is to use 7z - I tried and they actually keep the date as it is ... !
I use SyncBackFree for backing up from my Windows 10 desktop to the NAS. Who knows - maybe they can help out depending on what they use to copy. I'll send them an email.

Thanks again for the extensive reply. It is strange the "basic" data is there to get dates in from 1901 but the copying process does not support it.

Kind regards

Mijzelf

Johan52 said:

the copying process does not support it.

Samba is a bit more than a copying process. It's the open source implementation of Microsoft's SMB protocol and successors. As SMB is designed to share Windows files+metadata, and Samba usually runs on Linux or Unix hosts, Samba has to provide translation for all incompatible metadata. (Timestamps (Linux has microseconds since 1901, Windows 10nanoseconds since 1604), ACL (Linux has owner,group,world, Windows I don't know), filenames (Linux filesystems are case sensitive, Windows filesystems are not, in Linux filenames all characters are allowed (but not always practical), in Windows a lot are not allowed (:\*?...)).

Which is complicated. I suppose this issue is caused by conversion of Windows timestamps to Linux timestamps and back.