Question About Rsync and Modification Times

Kevin Korb kmk at sanitarium.net
Wed Oct 9 19:01:04 UTC 2024


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>
> 



More information about the rsync mailing list