rsync - Oct 2024 - Question About Rsync and Modification Times

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-bounces at lists.samba.org> on behalf of Kevin Korb via
rsync <rsync at lists.samba.org>
Date: Wednesday, October 9, 2024 at 14:45
To: rsync at lists.samba.org <rsync at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20241009/4c6616b1/attachment.htm>

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-bounces at lists.samba.org> on behalf of Kevin
Korb
> via rsync <rsync at lists.samba.org>
> *Date: *Wednesday, October 9, 2024 at 14:45
> *To: *rsync at lists.samba.org <rsync at 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>
>