That isn't how rsync should work with -a. Is something preventing it
from backdating the file? What is the filesystem? Can you try copying
your 2015 file with cp -a?
On 10/9/24 14:56, McDowell, Blake wrote:
Hi Kevin,
The -a flag in this instance is not back-dating the timestamp of the
copied file to the source file. It is modifying it to the time of
transfer and leaving it that way. Then any time I rerun that command it
always updates the timestamp since it is always making it the time of
transfer. I have a source file the has a modification date of 2015 and
when I rsync it to day with -a the copied file has a modification date
of today.
Again, this only happens on files that I use rsync to copy for the first
time over to empty storage. If I drag and drop the timestamp stays the
same as the source file and any rsync -a commands subsequently run do
not modify the file in any way. When I use rsync -a to copy over the
first time, the timestamp is modified to the current time and then
continues to update anytime I run rsync -a
-Blake
*From: *rsync <rsync-boun...@lists.samba.org> on behalf of Kevin Korb
via rsync <rsync@lists.samba.org>
*Date: *Wednesday, October 9, 2024 at 14:45
*To: *rsync@lists.samba.org <rsync@lists.samba.org>
*Subject: *Re: Question About Rsync and Modification Times
External Email - Exercise Caution
You are using rsync -a which copies (preserves) the timestamp. Meaning
that rsync will copy the file then back-date it to the timestamp of the
source file. Most copying tools do not do this though cp's -a does it
too. Note that your itemized output says that the timestamp is
different meaning that the file has changed since rsync last ran.
Without the -a (or the included -t) the itemized output would have shown
a 'T' instead of a 't' meaning "The timestamp is different and I'm not
fixing it.".
If the file wasn't being modified the timestamp wouldn't be different
and rsync would have just skipped it.
On 10/9/24 14:06, McDowell, Blake via rsync wrote:
Hello,
I have a question about how/why rsync updates modification times, which
I haven’t been able to find an answer to.
I have two locally connected storage devices running TrueNAS Core: one
is new and empty, while the other is filled with files.
When I run the following rsync command:
/rsync -avPh --itemize-changes --stats "${@}"/
to transfer files from the full storage to the empty one, the
modification times of the transferred files are updated to the time of
transfer. I understand that using rsync to transfer to an empty storage
may not offer any real advantage, and that the modification times are
updated because rsync "touches" the files. However, I would prefer for
rsync not to update the modification times, though I gather this might
not be possible.
For context, the /--itemize-changes/ output during the initial transfer
looks like this:
/>f++++++++++/
Now, if I wait for a minute and then run a dry run with the same command
on the files I just transferred, the output changes to:
/>f..t......./
If I actually rerun the command, rsync updates the modification times to
the current time. This behavior repeats endlessly each time I run the
command.
Interestingly, if I manually "drag and drop" the files to the empty
storage, the modification times remain the same as the original files,
which is the outcome I prefer. Moreover, if I run the same rsync command
(/rsync -avPh --itemize-changes --stats "${@}"/) on the files that I
dragged and dropped, rsync doesn’t transfer or update any file, and the
/--itemize-changes/ output looks like this:
/.f/
I’m puzzled as to why rsync behaves differently for files initially
transferred using rsync versus those transferred via drag and drop.
Could this behavior be more related to TrueNAS rather than rsync?
Any clarification would be greatly appreciated.
Thanks,
Bleakley
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.samba.org%2Fmailman%2Flistinfo%2Frsync&data=05%7C02%7Cmcdowellh%40si.edu%7Cfccb6ec4d6ea49df31ed08dce8927c85%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C638640963111753917%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Bl10Cbn3HhpoUOKIaeOnZOEYt4QXlHZWc5e1CnuSnO0%3D&reserved=0
<https://lists.samba.org/mailman/listinfo/rsync>
Before posting, read:
https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.catb.org%2F~esr%2Ffaqs%2Fsmart-questions.html&data=05%7C02%7Cmcdowellh%40si.edu%7Cfccb6ec4d6ea49df31ed08dce8927c85%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C638640963111780341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DHfdTKxDHHKQFEB1TQeQZpaKOUduFh%2Fx3SUQxBxEcI8%3D&reserved=0
<http://www.catb.org/~esr/faqs/smart-questions.html>
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
