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 t
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
a.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
Date: Wednesday, October 9, 2024 at 14:45
To: 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
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 meanin
Yes, cpio -l can be useful since cpio can easily operate on the output
from the very capable find command.
On 9/4/21 8:34 PM, Dan Stromberg wrote:
>
> I was thinking --link-dest too.
>
> Sometimes this can be done with cpio too; check out the -pdlv options.
>
> On Sat, Sep 4, 2021 at 4:57 PM Ke
I was thinking --link-dest too.
Sometimes this can be done with cpio too; check out the -pdlv options.
On Sat, Sep 4, 2021 at 4:57 PM Kevin Korb via rsync
wrote:
> Rsync does almost everything cp does but since it is designed to network
> it never got that feature. I was thinking maybe --link-
Rsync does almost everything cp does but since it is designed to network
it never got that feature. I was thinking maybe --link-dest could be
tortured into doing it but if it can I can't figure out how. BTW, you
have some pointless dots in there.
On 9/4/21 6:41 PM, L A Walsh via rsync wrote:
> I
On Thu, Feb 21, 2013 at 2:11 PM, Jason Keltz wrote:
> As far as I understand, even though rsync is running on the client, the
> server is trying to write the batch file locally?
>
No, the batch file is always output by whatever side is running the rsync
command. You either need to specify a pat
> Object: Re: Question about rsync and BIG mirror
Thanks for all your answers and advices. My problem seems on the side of
the 2MB line one time the whole 190GB data are synchronised. I will keep
in touch and give some feedbacks.
Thanks for all
--
To unsubscribe or change options: ht
Shachar Shemesh wrote:
> >While you're there, one little trick I've found that speeds up
> >scanning large directory hierarchies is to stat() or open() entries in
> >inode-number order. For some filesystems it makes no difference, but
> >for others it reduces the average disk seek time as on many
Jamie Lokier wrote:
>While you're there, one little trick I've found that speeds up
>scanning large directory hierarchies is to stat() or open() entries in
>inode-number order. For some filesystems it makes no difference, but
>for others it reduces the average disk seek time as on many common
>fi
Wayne Davison wrote:
> On Mon, Mar 06, 2006 at 07:18:45PM +0200, Shachar Shemesh wrote:
> > In fact, I know of at least one place where they don't use rsync because
> > they don't have enough RAM+SWAP to hold the list of files in memory.
> >
> > As far as future directions for rsync, I think this
Shachar Shemesh wrote:
> >Hmm. My home directory, on my laptop (a mere 60GB disk), does contain
> >millions of files, and it takes about 20 minutes to build the list on
> >a good day. 100Mbps network, but it's I/O bound not network bound.
> >
> >It looks a lot like the number of files is more sig
On Mon, Mar 06, 2006 at 07:18:45PM +0200, Shachar Shemesh wrote:
> In fact, I know of at least one place where they don't use rsync because
> they don't have enough RAM+SWAP to hold the list of files in memory.
>
> As far as future directions for rsync, I think this is the major place
> where rsyn
Jamie Lokier wrote:
>Hmm. My home directory, on my laptop (a mere 60GB disk), does contain
>millions of files, and it takes about 20 minutes to build the list on
>a good day. 100Mbps network, but it's I/O bound not network bound.
>
>It looks a lot like the number of files is more significant tha
jp wrote:
> 100gb of 4-40MB files sounds like my home PC full of digital photos I've
> taken. It backs up to a linux PC right beside it with rsync. I don't
> really call it that big a project for rsync. Big things for rsync are
> millions of files. At 100mbps, it takes a few seconds to build the
100gb of 4-40MB files sounds like my home PC full of digital photos I've
taken. It backs up to a linux PC right beside it with rsync. I don't
really call it that big a project for rsync. Big things for rsync are
millions of files. At 100mbps, it takes a few seconds to build the list.
I use the
Flames invited if I'm wrong on any of this, but:
Some (long overdue) backups indicate that network speed
should be much more important than cpu speed.
Your results will depend heavily on your exact mix
and I cannot think of any reasonable way to quantify it.
That said, this may help give you a clu
On Fri, 2006-03-03 08:02:55 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> // I wonder if this message has been posted, so I sent it again //
It was, but nobody answered yet.
> I'm preparing a plan for a production mode in my company: we need to
> mirror around 100GB of data trough a spe
[EMAIL PROTECTED] wrote:
>Hello,
>
> So: each night, from 0:00am to maximum 7:00am, the server will have to
>check the 100Go of files and see what files have been modified, then,
>upload them to the clients. Each file is around 4MB to 40MB in average.
>
>
Are the clients what you call the "mir
On Thu, Oct 23, 2003 at 08:21:34PM -0500, Chao,Eisen R. wrote:
> Hi All:
>
>
> I thought the default behaviour for Rsync was that it would only
> overwrite
> destination files that have a lesser date than the source file. Instead
No. Rsync _replaces_ the destination file. And if --times
is ena
Hi All:
I thought the default behaviour for Rsync was that it would only
overwrite
destination files that have a lesser date than the source file. Instead
I
have this:
Source
[EMAIL PROTECTED]
[/csapps115/IBMHTTPD/content-external/cna/html/meet]: ls -al meet.html
Most commonly, such an error means that the path line for the module in
question is invalid. Sometimes, it means the server system doesn't
support chroot.
check your rsyncd.conf, first.
Tim Conway
[EMAIL PROTECTED]
303.682.4917 office, 303.921.0301 cell
Philips Semiconductor - Longmont TC
1880
24 matches
Mail list logo
