Linux servers one running TrueNAS-13.0-U6 and the other running
TrueNAS-13.0-U3.1.
I connect to both on a Mac via smb over fiber.
Using cp -a also updates the timestamp of the copied file to today and does not
back-date it to the source file.
I’m not really a sysadmin, I’m a time-based media conservator/archivist, so I
may be missing something obvious.
-Blake
From: Kevin Korb <k...@sanitarium.net>
Date: Wednesday, October 9, 2024 at 15:01
To: McDowell, Blake <mcdowe...@si.edu>, rsync@lists.samba.org
<rsync@lists.samba.org>
Subject: Re: Question About Rsync and Modification Times
External Email - Exercise Caution
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%7Cf2da21cbb6de4ff1f18c08dce894bab1%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C638640972705519400%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ZY9fTKMyCvMorrgG7PfHbbRybpvFwTkb8a2SkkBW7no%3D&reserved=0<https://lists.samba.org/mailman/listinfo/rsync>
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.samba.org%2Fmailman%2Flistinfo%2Frsync&data=05%7C02%7CMcDowellH%40si.edu%7Cf2da21cbb6de4ff1f18c08dce894bab1%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C638640972705543377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=z1vcUUDiZbHn2rdp13C1PnTEYi0Ta%2FhZLBH1uBNYbRA%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%7Cf2da21cbb6de4ff1f18c08dce894bab1%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C638640972705556555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ubSqu9L85XZQvWdZOJXYEPw6QnMRPz6Y0PeldiBHxFE%3D&reserved=0<http://www.catb.org/~esr/faqs/smart-questions.html>
> <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%7Cf2da21cbb6de4ff1f18c08dce894bab1%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C638640972705568468%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6O9%2F1o97FvpmWWHJ0DegZWt3u%2Fk7WSrcPo2aMbJkpUU%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
