Bill in Co wrote:

I don't know why the default operation isn't necessarily to preserve the
source date and time stamps for all of these operations, for all of these
utilities (like zip, or whatever). I guess some folks figure the date of
the copy or extract operation is more imporant or more relevant than
preserving the source file date and time attributes.

Not only in this file transfer (which is a new file create and data
stream write, not actually physically moving the file) across file
systems but the transfer is also across operating systems. The new OS
is requested to create a new file and a data stream comes in to put into
the new file. How would one OS know the timestamps of the source file
in a different OS unless somehow the timestamps got touched by whatever
was controlling the copy operation on the new file? It isn't just
timestamps that can get lost. Permissions are OS based: when
permissions are assigned to a folder or file, only the OS in which the
permissions were defined knows what are those permissions. That's why
you can removed a drive from one computer and attach it as a data drive
in another computer to read protected files. The permissions were not
defined in the other OS, so they are not honored because they are not
known. There are lots of attributes that can be lost in a copy
operation between different file systems, say from NFTS to FAT32, and
especially for a transfer between operating systems.

Think of when you watch streaming media content in your web browser that
is delivered from a media server. Your end creates a container (e.g.,
cache or buffer) for the streamed content and you get the streamed
content but you have no clue of the timestamps, permissions, or other
attributes of the source file that gets streamed to you. The OS to
which a file gets streamed (aka transferred) also only knows it need to
create a container (file) for the incoming data stream (for the copy
operation). Unless something else touches the destination file, the
target OS's file system won't get all the other source file's
attributes.

Some transfer programs will attempt to copy the other source file
attributes onto the destination file but that is above the basic copy
operation. They may attempt to change (touch) the destination file's
timestamps, set the basic file attributes (those you see using the
attrib command), and may even attempt to set permissions the same on the
target file as for the source file (except that user SIDs won't be the
same, so they can only likely set permissions for the global SIDs and
for the account under which the copy operation is running on the target
OS). The transfer tool has to do more than just a copy operation.

One suggestion that I mentioned (that I found others had mentioned) was
using an FTP server on the target OS. It will touch the destination
file to keep the timestamps of the source file; however, I can't see FTP
also maintaining the permissions in an FTP file transfer. It's
possible, just like with sync tools, but those operations would be in
addition to the standard FTP protocol which doesn't understand
permission attributes in the source and target OS scheme, especially
since you can FTP from Windows to Linux which don't use the same
permissions schemes. A robust FTP server and client might be able to
alter permissions on the newly created target file along provided the
permission schemes were the same at both ends but just running the
ftp.exe command line program that just does simple FTP is only going to
have the FTP server create the new file and write the data stream into
it (and try to match the timestamps in the destination file). In fact,
unless I test, I'm sure sure basic FTP even tries to duplicate the
timestamps onto the destination file to match those of the source file.
In a command shell, run "ftp /?" and there are no command-line switches
regarding timestamps.

http://logic.edchen.org/3-steps-to-m...rve-timestamp/

Even Filezilla which is more robust than a command-line ftp.exe program
cannot preserve timestamps unless:

- You enable the option in Filezilla.
- AND (*very important*) the FTP server supports MFMT command (to modify
the Last Modified timestamp) and MFCT (to modify the Create timestamp)
of the destination file (the new created one into which the data
stream gets copied from the source file).

The MFMT command was not part of the original FTP specification. The
command was added later as an extension to FTP. The extension is still
just a draft (back in 2002); however, that draft expired(*) and I
couldn't find where it got ratified into an RFC for an extension to FTP.
This means many FTP servers don't support those commands.

(*) Some references say the draft has expired. Other references note
the draft is experimental (which implies it has not expired) and
with an update timestamp of 2008.

When the OP zipped up the files into an archive file (.zip), that tool
added fields to each file record to track the timestamps of the original
files. When he looked inside the archive file, yep, those would be the
timestamps for those files but only within that "file system"
(database). If he ever extracts those files out of that archive, he
relies on whatever tool he uses to not only create a new file in the
destination file system but to also touch the new file's attributes to
make its timestamps the same as recorded in the archive's record for the
data block (aka file). Permissions are not recorded in a .zip file
(just timestamps), especially since the archive may get transported to
dissimilar OSes (Windows to Linux), so extracting the files from the
archive will mean those new files get whatever permissions under
whatever account the user performed the extraction.

https://en.wikipedia.org/wiki/Zip_(f...)#File_headers

You hope that whatever tool you use to extract data block from the
archive file will also read the Last Modification Time header for that
record and use it to touch the newly created destination file into which
the data block gets copied. Notice there is no header for the Create
timestamp, just the Modified timestamp. That means after extraction
that the newly created destination file could have a Modified timestamp
that is before its Create timestamp. The source file might've been last
modified months ago but the destination file for the extraction was just
created today.