Hi Steve,
I run my first transfer always as rsync -avvPh. I now add in -i based on
what I’ve learned here.
My understanding from the rsync man page is that -a or ―archive implicitly
includes -t or ―times. Am I mistaken there? Do I need to run ―times
separately?
The output of my first transfer i
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 output from --itemize-changes.
>Gives me the following for most files >f..T...
I ran the original transfer with the -a flag. It doesn't fix the problem.
-Original Message-
From: rsync [mailto:rsync-boun...@lists.samba.org] On Behalf Of Kevin Korb
Sent: Wednesday, June 08, 2016 8:26 PM
To: rsync@lists.samba.org
Subject: Re: rsync keeps writing files over
Hi Kevin,
Stat is pretty cool! But, I can’t quite figure out some of the stuff it is
telling me right now.
I’ll try using —update but I’m hoping to figure out why the timestamps are
not transferring on the majority of my files.
Thanks,
Blake
On 6/2/16, 6:58 PM, "rsync on behalf of Kevin Korb"
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
>
> Gives me the following
Hi Steven,
Yes, both file systems are the same.
rsync -nri --modify-window=1
Gives me the following for most files >f..T...
2015_167_1_1__Boy_What_A_Girl_R2/2015_167_1_1__Boy_What_A_Girl__UHD_DPX_R2/
BWAG_R2_00138428.dpx
Although a few have >f..T..n
2015_167_1_1__Boy_What_A_Girl_R2/20
Hi Perry,
The issue I¹m having is not writing to the LTO tape - rsync does that ok,
but we have just switch over to gcp followed by rsync as a double-check.
It has certainly helped with our LTO writing.
The problem I¹m having with the files continually re-writing is for a
local transfer from exte
Thanks for that info Simon.
The files system is Journaled HFS+ and I¹m running rsync version 3.1.2
protocol version 31.
I run rsync exclusively through the CLI/Terminal, so I¹m not sure what the
version that comes with OSX is, but it is not the GUI version.
On 6/3/16, 5:17 AM, "rsync on behalf
per...@pluto.rain.com (Perry Hutchison) wrote:
> Best choice for magtape is probably something like tar, cpio, or pax
> (for a file-oriented backup), or the appropriate variant of dump(8)
> (to back up an entire filesystem -- but not all FS formats have a
> dump/restore suite available).
I wouldn
"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 is "hacked" to handle the file semantics
of HFS+ filesystems. Hopefully someone else ac
"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 of note - this
> problem doesn't exist for every file, just the vast majority.
> So, that just makes it more confusing.
The filesystem format (MacOS native?
In , on 06/02/16
at 10:42 PM, "McDowell, Blake" said:
Hi Blake,
>The storage is just an regular HDD in a mac pro tower. I can t imagine
>why it wouldn t handle timestamps. Also of note - this problem doesn t
>exist for every file, just the vast majority. So, that just makes it more
>confusing
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 Thanks!
>
> Specifically, the timestamps on both and m
Cool Thanks!
Specifically, the timestamps on both and match for "ls -l"
but do not match for "ls -lu" or "ls -lc”
The storage is just an regular HDD in a mac pro tower. I can’t imagine why
it wouldn’t handle timestamps. Also of note - this problem doesn’t exist
for every file, just the vast maj
The man page has a section on what all the itemize-changes flags do.
There is a --ignore-times but the result is what you have now, re-copy
everything even if the timestamp matches.
The best you can really do with storage that can't handle timestamps is
to use --update. But if you do that you ne
OK. Thanks. Where can I find information regarding how to interpret
—itemize-changes?
The timestamps aren’t changing, so the target must not be storing them,
which I have no idea why. The directory I’m writing to is 777.
What is the flag to tell rsync to ignore the timestamps?
Thanks,
Blake
On
It is saying the timestamp is wrong and that it is copying the file and
changing the timestamp. If it does that every time then either the
timestamps are changing on the source or the target isn't storing them.
On 06/02/2016 06:13 PM, McDowell, Blake wrote:
> Thanks Kevin! I¹m unclear how to read
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 one computer.
rsync -aPh --itemize-changes -n
/Volumes/shuttle_05/2012_79_1_14_1__1199_Workprint /Volumes/3TB_LTO/
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
Instead 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 wrote:
> Hi,
>
>
>
> A
20 matches
Mail list logo
