conservator/archivist, so I
may be missing something obvious.
-Blake
From: Kevin Korb
Date: Wednesday, October 9, 2024 at 15:01
To: McDowell, Blake , rsync@lists.samba.org
Subject: Re: Question About Rsync and Modification Times
External Email - Exercise Caution
That isn't how rsync s
7; 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,
>
>
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
Transferring files to our NAS over fiber. Nothing unusual...
From: Kevin Korb [k...@sanitarium.net]
Sent: Friday, April 07, 2017 3:08 PM
To: McDowell, Blake; rsync@lists.samba.org
Subject: Re: modification times questions
I have never seen rsync do that
nt is correct you can run rsync with both
--times and --size-only.
This will cause rsync to "fix" the timestamps on files that are the same
size on both ends.
On 04/07/2017 02:53 PM, McDowell, Blake via rsync wrote:
> How do I transfer just the modification times with rsync? I now the fil
How do I transfer just the modification times with rsync? I now the file
content is the same but the modification times are different. Is there a way to
do this? Every way that I have tried causes the whole file to transfer as well.
Thanks
--
Please use reply-all for most replies to avoid omitt
Hello,
We have our mac connected to a SAN via 10Gbe fiber network. Being thunderbolt
model macs with no PCI slots we are using external boxes (Sonnet, ATTO) to
interface between the thunderbolt and fiber connections.
When using rsync -avvPhi we get speeds of approx 110MB/s but with a simple
Thanks Paul. That should help!
Kevin,
For a local copy is running a plain rsync transfer ( rsync )
essentially the same as a "drag-and-drop"?
The benefits of using rsync in that situation would all come from choosing
flags appropriate to the desired transfer?
Thanks,
Blake
-Original M
rk mount of some kind to make it a local copy instead of letting rsync do
the networking.
Anyways, if rsync isn't doing the networking then forcing it to do a delta
transfer would only make it take even longer.
On 06/24/2016 02:59 PM, McDowell, Blake wrote:
> Hi Kevin,
>
> I h
tch.
Unless of course --whole-file.
On 06/24/2016 11:47 AM, McDowell, Blake wrote:
> Hello,
>
>
>
> I’m running rsync -avPhi to move large video files to a remote server.
> Often we have to stop a transfer midway through to push something
> else to the server. My hope was
Hello,
I’m running rsync -avPhi to move large video files to a remote server. Often
we have to stop a transfer midway through to push something else to the server.
My hope was that the -P flag would invoke --partial and the transfer would
pick-up where it left off. This does not seem to be hap
even Levine"
wrote:
>In , on 06/09/16
> at 12:17 AM, "McDowell, Blake" said:
>
>Hi Blake,
>
>Please reply to the list.
>
>>rsync -nri --modify-window=1
>
>As others mentioned, you need need to use --times. This is needed so that
>we can see use
the T means that the timestamp is wrong and rsync is not fixing it because you
don't have --times or --archive in your command line.
On 06/08/2016 08:17 PM, McDowell, Blake wrote:
> Hi Steven,
>
> Yes, both file systems are the same.
>
> rsync -nri --modify-window=1
>
>
Korb"
wrote:
>Rsync only cares about the modification time. The ls command usually
>abbreviates the timestamp so it is better to use the stat command on one
>of the problem files to see the full thing.
>
>On 06/02/2016 06:42 PM, McDowell, Blake wrote:
>> Cool T
es.
-rwxrwxrwx 24,839,552 2016/05/27 14:00:57 BWAG_R2_00130798.dpx
-rwxrwxrwx 24,839,552 2016/05/27 14:00:57 BWAG_R2_00130798.dpx
I¹m running version 3.1.2 protocol 31.
Thanks,
Blake
On 6/2/16, 7:26 PM, "rsync on behalf of Steven Levine"
wrote:
>In , on 06/02/16
> at 1
external HDD to internal HDD, both HFS+
Thanks,
Blake
On 6/3/16, 4:14 AM, "Perry Hutchison" wrote:
>"McDowell, Blake" wrote:
>
>> The storage is just an regular HDD in a mac pro tower. I can't
>> imagine why it wouldn't handle timestamps. Also o
nc on behalf of Simon Hobson"
wrote:
>"McDowell, Blake" wrote:
>
>> The storage is just an regular HDD in a mac pro tower.
>
>Ah, is this the version of rsync that comes with OS X ? Are these HFS+
>filesystems ?
>
>I vaguely recall that the OS X version i
, are you using rsync to copy files to a tape drive? If so then I
>would think rsync is not the right tool for dealing with linear storage.
>
>On 06/02/2016 06:25 PM, McDowell, Blake wrote:
>> OK. Thanks. Where can I find information regarding how to interpret
>> —itemize-chan
gt;
>On 06/02/2016 06:13 PM, McDowell, Blake wrote:
>> Thanks Kevin! I¹m unclear how to read the ‹itemize-changes output. Can
>>you
>> provide some insight?
>>
>> This is a local transfer from an external drive to an internal drive all
>> attached to on
nstead of the second -v (or even the first) add --itemize-changes. It
>will tell you why each file is being copied. If the file timestamps are
>not correct then perhaps the underlying storage doesn't allow arbitrary
>mtime changes.
>
>On 06/02/2016 05:23 PM, McDowell, Blake w
Hi,
At my work we use rsync to move files between drives and to LTO among other
things.
I'm having an issue using rsync to move material between and external drive and
an internal drive.
We run "rsync -avvPh " and most of the files keep writing every
time I run this. It appears that the modi
21 matches
Mail list logo
