Re: Question About Rsync and Modification Times
On Wed 09 Oct 2024, McDowell, Blake via rsync wrote: > 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. This sounds lke the implementation of TrueNAS is not doing what it should. Paul -- 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
Re: Question About Rsync and Modification Times
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 Date: Wednesday, October 9, 2024 at 15:01 To: McDowell, Blake , [email protected] 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 on behalf of Kevin Korb > via rsync > *Date: *Wednesday, October 9, 2024 at 14:45 > *To: *[email protected] > *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 rela
Re: Question About Rsync and Modification Times
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 on behalf of Kevin Korb via rsync *Date: *Wednesday, October 9, 2024 at 14:45 *To: *[email protected] *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/s
Re: 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 on behalf of Kevin Korb via rsync Date: Wednesday, October 9, 2024 at 14:45 To: [email protected] 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
Re: Question About Rsync and Modification Times
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://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
