I'm not really blaming the user. If it were up to me, -v would include -i.
On 2/9/24 05:36, Andreas Gruenbacher wrote:
On Sun, Feb 4, 2024 at 7:20 PM Kevin Korb via rsync
wrote:
rsync's -v is fairly useless. Learn to use -i instead or in addition to.
Well, note that I didn't say anything
now it sounds like you have too many hard links for rsync to handle.
On 2/7/24 08:05, Franke via rsync wrote:
Am 06.02.24 um 23:20 schrieb Roland:
and then, it stops totally quiet.
you mean it simply exits without any message?
Yes rsync ends totally quit.
what's the return code ( echo
Normally, when rsync isn't deleting things the problem is that there is
some kind of error (possibly scrolled off screen unnoticed) but it
sounds like you are getting no output at all which would eliminate that
possibility.
The other likely cause is your $SOURCE being something that contains a *
rsync's -v is fairly useless. Learn to use -i instead or in addition to.
On 2/4/24 12:58, Andreas Gruenbacher via rsync wrote:
Hello,
when trying to rsync files between hosts, I ran into a surprising case
in which rsync replaces a symlink with a directory, with no indication
of any kind.
In
Also, instead of -a use -rt. Those are the only parts of -a that FAT
even pretends to support.
On 1/21/24 16:42, Roland via rsync wrote:
it's most likely because of vfat timestamp limitation
try
--modify-window
When comparing two timestamps, rsync treats the
timestamps as
l.com>> wrote:
Hi,
On Wed, Dec 20, 2023 at 11:03 AM Kevin Korb via rsync
mailto:rsync@lists.samba.org>> wrote:
What is the error? I assume you know that with that syntax the
filelist.txt is local rather than remote.
Yes, I do know i
What is the error? I assume you know that with that syntax the
filelist.txt is local rather than remote.
On 12/20/23 09:50, Alex via rsync wrote:
Hi, I've been using rsync on fedora over ssh to sync directories for
decades, but suddenly having a problem with transferring multiple files
at a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Unfortunately, exit 23 litterally just means something else went wrong
and might have scrolled off of the screen if you have rsync listing
files (--verbose or --itemize_changes). Essentially, it is anything
that doesn't have its own exit code. I
-0400, Kevin Korb via rsync wrote:
I have heard in the past that rsyncing an empty dir over a tree to
delete the tree is faster than an rm -rf but I can't say I have ever
benchmarked it to get any actual numbers.
This **may** indeed be a myth (for a long time now) re-cited again and again
I had intended to come back to this but because I didn't really think I
had anything to add to the discussion I put it at a low enough priority
that I forgot about it. But I saw your bug report and was surprised to
see that I was already unhelpful on this topic but because that original
Is this being accessed via a fuse mount? If so it seems like that is
where this kind of feature should be implemented (like a mount option to
decide how to handle such files). Rsync shouldn't need special features
to deal with every kind of file storage.
On 9/12/23 05:22, Brian "bex"
You have --itemize-changes but either it didn't or you filtered it out.
--
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
Kevin Korb Phone:(407) 252-6853
Systems Administrator Internet:
FutureQuest, Inc.
find /mnt/foo/* -maxdepth 0 -print -exec rsync -an `realpath {}`
/mnt/bar/ \;
(realpath eliminates the trailing slashes)
On 8/3/23 22:27, Fourhundred Thecat via rsync wrote:
Hello,
I am copying /mnt/foo to /mnt/bar/
rsync --info=name1,del2 -rl /mnt/foo /mnt/bar/
/mnt/foo contains deep
NFS is slowing things down even more than your bandwidth measurements as
it is also forcing --whole-file.
On 8/2/23 05:03, Perry Hutchison via rsync wrote:
Sebastian G??decke via rsync wrote:
We're facing some flapping traffic when rsyncing atm 70T from
one server to an DELL Isilon.
Both
You should also read about --inplace. Without it --no-whole-file you
are telling it to do all the extra data diffing only to write out an
entire new file anyway (just using data from source and target to create
it).
On 6/30/23 21:29, Selva Nair via rsync wrote:
So this disable a lot
On 6/29/23 16:31, Stephane Ascoet via rsync wrote:
Kevin Korb le 29/06/2023 04:52:
--itemize-changes will cause rsync to tell you what it thinks is
Hi, thank you so much! Today I used a little different way of doing it,
and another computer, and the behaviour is the same. It seems that the
--itemize-changes will cause rsync to tell you what it thinks is
different. Also, -z is counter-productive when rsync isn't networking.
On 6/28/23 22:28, Stephane Ascoet via rsync wrote:
Hi, /media/clec1enextsanstampon/gigamopourcdas4/ contains an old copy of
files of /media/mo. I'm
on.
*From:* rsync on behalf of Kevin Korb
via rsync
*Sent:* Wednesday, June 7, 2023 3:26 PM
*To:* rsync@lists.samba.org
*Subject:* [External] Re: ctrl -c while executing --progress --size-only
--partial results in unhidden but incomplete file
[You don't often get email from rsync
That is what --partial does. It keeps the partial file. If it kept the
temporary file with the random file name that would just be a useless
orphaned file.
On 6/7/23 15:02, Lacey, Nathan via rsync wrote:
This is a clone from https://github.com/WayneD/rsync/issues/484
The only way I know of to determine this behavior is to use the
--link-dest option in rsync OR use the much older cp -al then rsync over
top of it method. With --link-dest a change in the file's metadata
causes rsync to duplicate the file in order to store both versions of
the metadata. With
I am not 100% sure I am interpreting this correctly but I think you are
complaining that the file was being deleted in the first command? If
so, instead of -F try --include='*/' --exclude='*'. Otherwise, maybe
you want a second -F?
On 3/6/23 16:04, Heiko Schlittermann via rsync wrote:
The included github test case failed for me on vanilla rsync-3.2.7...
% ./test.sh
new.bin test.bin differ: byte 28345, line 1
% md5sum -b *.bin
7e11df4130968b5e4859f58b9bd6b453 *initial.bin
ff14ab080514d5681c99e4e1de01e29f *new.bin
151dd8b1c7bd628afcf38ac6c44155be *test.bin
% rsync --version
The first "Bug Fix" listed in
https://rsync.samba.org/ftp/rsync/NEWS#3.2.4 is almost certainly
related. Apparently it was fixed via remote option but since your test
doesn't include networking that fix wouldn't help.
On 12/8/22 15:03, Mark Raymond via rsync wrote:
I believe I have found a
Rsync does not have a --no-clobber. -n is --dry-run. It shows what
rsync would do without actually doing it. But I didn't know you were
using --backup. Anyway, I tried it again with --backup and
--remove-source-files and it did in fact delete all the files (but not
the dirs). It didn't
I think I must be missing something. If source and dest are the same
place rsync shouldn't do anything unless it it responding to changes
happening at the same time. For example, when I do 'rsync -vain
--remove-source-files /tmp/ /tmp/' rsync does nothing.
On 10/17/22 23:12, Sridhar
You can put it all in quotes. Also, if you are scripting you might find
setting $RSYNC_RSH easier.
On 10/7/22 04:46, c.buhtz--- via rsync wrote:
Hello,
rsync does offer the --rsh argument. I would like to use it that way
rsync --rsh=ssh -o ServerAliveInterval=240 -o LogLevel=Error -o
solve my
problem? Will give it a try.
Am 25.09.22 um 20:30 schrob Kevin Korb via rsync:
-a is telling rsync to copy the metadata. --size-only is telling
rsync to skip the contents of files that are the same time. Without
--link-dest rsync would just update the metadata on the target.
However
-a is telling rsync to copy the metadata. --size-only is telling rsync
to skip the contents of files that are the same time. Without
--link-dest rsync would just update the metadata on the target.
However, with --link-dest rsync is being told to make the same file with
2 different metadatas.
You aren't logging any stderr. That is where any error messages would
go. Add some 2>&1.
Also, mount has a -v
On 9/24/22 09:15, dotdeb--- via rsync wrote:
I've been using rsync for years to backup my machines both at work and
at home.
These days I faced a new "challenge": at work I connect
You are using rsync over ssh. The connection timeout (and port) options
don't matter if rsync isn't doing the networking.
On 9/1/22 08:49, Roland via rsync wrote:
hello,
i do some backup via rsync/ssh and pull data from remote machine to
local machine.
whenever on remote machine there is
.
Or, alternately, be in a situation where a bit flip would be
catastrophic. Such situations are not common.
On Thu, Jul 14, 2022 at 04:26:48AM -0400, Kevin Korb via rsync wrote:
You should almost never use --checksum. It is slower than just re-copying
everything. You should almost always use
You should almost never use --checksum. It is slower than just
re-copying everything. You should almost always use --times (or
--archive which includes --times). Without this rsync is almost as dumb
as cp. Also, ssh has been the default --ssh for a long time.
On 7/14/22 04:22, Fourhundred
there are legitimate causes for that.
On 7/12/22 17:26, Paul Slootman via rsync wrote:
On Tue 12 Jul 2022, Kevin Korb via rsync wrote:
Rsync does not verify writes. --checksum doesn't verify anything. Sounds
like you want a file verification tool. The simplest would be md5sum.
Running rsync --checksum
Rsync does not verify writes. --checksum doesn't verify anything.
Sounds like you want a file verification tool. The simplest would be
md5sum.
On 7/12/22 02:31, Mark Filipak via rsync wrote:
Hello. Does rsync verify its writes?
Re, 'info rsync'.
Maybe I just being stupid, but there's no
It actually does that by default. Though you might need to add to the
list of file types with --skip-compress.
On 6/24/22 19:35, Joseph Garvin via rsync wrote:
I have an rsync cron job to backup folders that contain many different
types of files. Most of these are uncompressed files, so the
for the reply.
пт, 24 июн. 2022 г. в 19:00, Kevin Korb via rsync <mailto:rsync@lists.samba.org>>:
I think you are thinking too much of rsync here. Rsync groups are the
same as users they just have an @ in front of the name. If you want
UNIX style users and groups then use rsync
I think you are thinking too much of rsync here. Rsync groups are the
same as users they just have an @ in front of the name. If you want
UNIX style users and groups then use rsync over ssh and get the bonus of
ssh's authentication as well as not needing an rsyncd.conf file at all.
On
includes
and excludes into the same file.
On 4/30/22 20:48, H via rsync wrote:
On 04/30/2022 08:22 PM, Kevin Korb via rsync wrote:
Includes override excludes that follow. So, your include of * meant that
nothing was being excluded. An exclude before any includes isn't affected by
the includes
Includes override excludes that follow. So, your include of * meant
that nothing was being excluded. An exclude before any includes isn't
affected by the includes.
On 4/30/22 20:04, H via rsync wrote:
On 04/30/2022 07:56 PM, H via rsync wrote:
Ah, I was under the impression that all
Rsync includes a script named rrsync that handles this perfectly.
On 3/12/22 01:08, Richard Hector via rsync wrote:
On 12/03/22 18:38, Richard Hector via rsync wrote:
And I do my backups (using dirvish) as root, using a key with a forced
command.
FWIW, that forced command is here:
Are you using the same source and target each time? I ask because the
only discrepancy I see is the link count which shows that there are 11
more instances of that inode on the source than the target. Maybe
instances in other snapshots are being updated/re-linked?
The only other thing to
wrapper that works very well over networks but
is similarly very slow over local disks. I thought it was a bug in my
code but didn't get around to tracking it down since my use cases were
all network/ parallel file systems.
Harry
On Sun, Nov 28, 2021, 11:43 AM Kevin Korb via rsync
mailto:rsync
rsync is terribly slow at local copies. Also, it doesn't do its normal
optimizing (see --whole-file). Just use cp.
On 11/28/21 13:38, Mario Marietto via rsync wrote:
Hello to everyone.
I'm copying a large file from a NTFS formatted disk to another
one,UFS/FreeBSD disk,both are removable
rsync have anything similar?
>
> Kevin Korb via rsync wrote:
>
>> There maybe a proper solution but an obvious workaround would be to run
>> rsync twice. The first time without the --fileflags option.
>>
>> --no-perms wouldn't help. That is only the standard unix
There maybe a proper solution but an obvious workaround would be to run
rsync twice. The first time without the --fileflags option.
--no-perms wouldn't help. That is only the standard unix permissions.
On 10/30/21 8:04 PM, Fred Fugate via rsync wrote:
> Hi,
>
> I have some subdirectories
See --link-dest. That is what makes rsync shine for backups.
On 10/6/21 10:09 AM, Helmut Jarausch via rsync wrote:
> Hi,
>
> I'd like to mirror my root file system (e.g.) to a different disk. The
> mirror should always be most recent.
> In addition, I'd like to be able to restore my file system
:
>>
>>> ‐‐‐ Original Message ‐‐‐
>>> On Saturday, September 18, 2021 12:06 AM, Kevin Korb via rsync
>>> rsync@lists.samba.org wrote:
>>>
>>>> Not really sure what you are trying to accomplish here. Seems like it
>>>> should work the way you h
Well, what you have should function. But rsync is going to sort the list.
On 9/17/21 8:26 PM, hancooper wrote:
> ‐‐‐ Original Message ‐‐‐
> On Saturday, September 18, 2021 12:06 AM, Kevin Korb via rsync
> wrote:
>
>> Not really sure what you are trying to accomplis
Not really sure what you are trying to accomplish here. Seems like it
should work the way you have it. Note that many wonky rsync kludges are
due to people not realizing that rsync can have multiple source
arguments. Instead of the source simply being . it can be a list of
stuff. Also, note
-av
> --inplace ?
>
> What can I do for the files which have been sent but got rsync aborted during
> transfer?
>
>
>>> On 9/11/21 9:29 PM, hancooper wrote:
>>>
>>>> ‐‐‐ Original Message ‐‐‐
>>>> On Saturday, September 11, 2021 11:20 P
:20 PM, Kevin Korb via rsync
> wrote:
>
>> --archive is all you really need. I actually wish --archive was the
>> default because it is all most people need and with the exception of
>> writing to a FAT filesystem it is almost always needed.
>>
>> --append
--archive is all you really need. I actually wish --archive was the
default because it is all most people need and with the exception of
writing to a FAT filesystem it is almost always needed.
--append is for very special cases and should only be used if you really
know you need it and why.
4, 2021 at 4:57 PM Kevin Korb via rsync
> mailto:rsync@lists.samba.org>> wrote:
>
> 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 i
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:
>
wrote:
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, August 24, 2021 8:25 PM, Kevin Korb via rsync
> wrote:
>
>> In my experience backing up multiple hosts to a single host can speed
>> things up. Especially if using rsync over ssh with multiple CPUs on the
>> sin
In my experience backing up multiple hosts to a single host can speed
things up. Especially if using rsync over ssh with multiple CPUs on the
single host. You would need to do some experimentation to determine the
best number for your hardware and network. Also, if you exceed that
number you
Rsync by default displays nothing. There are more than one options that
tell it to display the files it is touching. There are other (and
duplicate) options that tell it to show everything. You didn't say what
options you are using so we have no idea. Except that you aren't using
Short answer: Don't use --append[-verify]
If you aren't syncing files that aren't tagged with 'chattr +a' you
don't want --append. --append-verify is essentially "I think --append
is a good idea to use on general files but rsync keeps corrupting
stuff!" but it still allows files to be out of
Those aren't really rsync errors they are just rsync telling you what
the kernel told it. The only thing I see wrong in your paste is that
you didn't use a trailing / on the source+target. Those do mean
something to rsync. The only thing I see wrong in the instructions is
the use of dd to make
You should both look into rrsync. It comes with rsync and is designed
to do exactly this. Unfortunately some Linux distros are maintained by
insane people who install rrsync as if it was documentation (compressed
and not executable) instead of a helper script which is what it is.
On 2/18/21
I am not sure if I have missed information here but... Rsync only sets
the mtime on files that it completely transferred. The back-dating of a
file is rsync's guarantee that that file was completely transferred and
verified.
On 2/2/21 9:03 PM, Leon Vanderploeg via rsync wrote:
> Windows Cygwin
and with the --archive flag (preserve symlinks).
>>>
>>> The result was the symlinks on the destination volume were preserved or
>>> at least not destroyed by the subsequent sync. If this test is what you
>>> intended then it shows rsync can preserve the symlink between N
volumes but I would have to manually recreate the symlinks on the
> destination NTFS volume once.
>
> Have I understood correctly?
>
>
> On Tue, 29 Dec 2020 at 13:53, Kevin Korb via rsync
> mailto:rsync@lists.samba.org>> wrote:
>
> If you delete the li
If you delete the link then restore it does it start working again when
in the correct place?
Also, don't use --checksum unless you are really certain you understand
how terribly slow it is and how it doesn't actually accomplish much of
anything (certainly not any kind of data verification).
On
Either that or you have a hardware problem causing the checksum routine
to return the wrong result.
On 12/15/20 11:47 PM, Dan Stromberg via rsync wrote:
>
> On Tue, Dec 15, 2020 at 3:25 AM Laurent B via rsync
> mailto:rsync@lists.samba.org>> wrote:
>
> Dear all,
>
> I'm encountering a
A few things here...
What filesystem is on /mnt/sony?
Add a --itemize-changes to see what it says is going on.
There really isn't a good reason to exclude lost+found. It should always
be empty and take up no space. If there is something in it that is a
sign that there is a problem with your
You need to include the dirs leading to there...
--include=httpd/, --include=httpd/conf.d/
Otherwise it will never look inside to see the cluster.d
(I am assuming you are right about lsyncd using the same patterns as rsync).
On 10/21/20 9:01 AM, lejeczek via rsync wrote:
> hi guys,
>
> I'm
Interesting idea. It isn't something I have ever wanted to do. BTW, if
your find is recent use + instead of \;. + replaces {} with however
many entries fit in the command line length limit instead of running
individual rsync processes for each entry.
On 9/29/20 7:46 PM, Rob Campbell via rsync
On 9/29/20 7:07 AM, joe--- via rsync wrote:
> unknown module Linux1
This would imply that "Linux1" is not defined in the rsyncd.conf file on
the backup server. Of course since it is a NAS appliance I don't know
if you have any access to the config file.
1 check you could run is 'rsync
Mostly it means that the file rsync ended up with on the target end
didn't match the file on the source it started with. This is mostly
caused by the file being modified on the source while rsync is copying
it but it can also be a memory corruption problem.
On 8/11/20 1:13 PM, Peng Yu via rsync
user@x.x.x.x:port/ModuleName is not correct syntax. You may have
something in your shell config translating that for you. Correct syntax
is --port and user@host::module
On 6/25/20 6:01 PM, Chandrasekar Natarajan via rsync wrote:
> Hi,
>
> I am trying to pull folders from a windows remote
Unfortunately the hard links are the problem. In order to keep them
straight rsync has to remember the details of every file it finds with a
link count >1 making it grow and grow. Of course without -H rsync will
end up duplicating them.
On 6/25/20 10:30 AM, Andy Smith via rsync wrote:
> Hi,
>
The only time I have seen something like that was when I was using rsync
to backup a snapshot and something went wrong in the snapshot creation
resulting in me rsyncing an empty dir instead of a mounted filesystem.
Does the --stats output imply that rsync saw an empty dir?
On 6/9/20 2:46 AM,
On 5/6/20 11:49 AM, Peng Yu wrote:
> On 5/5/20, Kevin Korb via rsync wrote:
>> Rsync != diff.
>
> What do you mean? I only need to know what files are not the same, but
> I don't need to know what the differences are with the files.
See diff -q
>
>> However, i
Rsync != diff.
However, if that command lists a file something is different about it.
add --itemize-changes to find out what.
On 5/5/20 8:47 PM, Peng Yu via rsync wrote:
> Hi,
>
> I use this command. But it also shows the files that are the same. Is
> there an option that can be specified so
file mode?
>
> On Thursday, March 12, 2020 6:26:18 PM CET, Kevin Korb via rsync wrote:
>> I would expect that the sending rsync would only send the perms provided
>> modified by the --chmod. I wouldn't expect the receiver to even know
>> the other permissions.
>>
>> On 3
t;
> On Thursday, March 12, 2020 6:06:34 PM CET, Kevin Korb via rsync wrote:
>> Permissions don't require super. Any place where permissions can't be
>> stored certainly can't handle xattrs either. So, I wouldn't expect
>> --fake-super to affect --perms at all.
>>
>&
Permissions don't require super. Any place where permissions can't be
stored certainly can't handle xattrs either. So, I wouldn't expect
--fake-super to affect --perms at all.
On 3/12/20 12:46 PM, Dimitrios Apostolou via rsync wrote:
> rsync --perms -M--fake-super src dst
>
> For me, this
If you used -v then the very last line rsync outputs is:
total size is ### speedup is ### (DRY RUN)
--
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
Kevin Korb Phone:(407) 252-6853
Systems Administrator Internet:
Either format is correct. However, there is no quoting or escaping in
the file. So:
- filename1
- file name 1
or without the -
On 1/3/20 1:45 PM, @lbutlr via rsync wrote:
> I have seen two main styles in examples for using rsync with exclude-from.
>
> The first is simply a list of filename,
Order matters. --include overrides --exclude listed later. So, your
exclude is nullified by both of your includes. So move the exclude
before the includes. Of course then your includes will be irrelevant so
just remove them unless you are leaving out details.
On 12/28/19 9:15 PM, H via rsync
The reason for that is pretty simple... Rsync isn't reading the
existing file to find out that it is the same. Doing so would normally
be a waste of rsync's time. A better question is why are your files
changing timestamps when the data is the same.
On 12/18/19 6:47 PM, Wayne Piekarski via
When I try it the chmod works on both the real permissions and the
permissions in the xatttr. Maybe the behavior has changed since
whatever version you have (3.1.3 here) but this probably wouldn't help
you either.
On 12/8/19 7:56 PM, Dimitrios Apostolou via rsync wrote:
> Hello list!
>
>
It does seem impossible. I would suggest adding --itemize-changes (-v
isn't really all that useful without it anyway). If entries are still
missing then I would suspect that either log files are missing (maybe
duplicate file names replacing the occasional log file?) or something
other than rsync
It is a little confusing but in order to have an exclude dir merge
filter do both things (prevent transfer and prevent deletion) then it
needs to be on both ends of the transfer. The file on each end only has
partial effect on what rsync does.
Think of it like a file you (as a regular user) can
I believe you can shorten that to:
+ /some/very/
+ /some/very/deep/
+ /some/very/deep/path/
+ /some/very/deep/path/to/
+ /some/very/deep/path/to/save/***
- /some/*
You could also exclude /some and then use /some/very/deep/path/to/save
as an additional source. I don't know if rsnapshot can
In addition to the cron problems that others have pointed out there are
rsync problems...
#1 rsync's -c is almost always a bad idea and is extremely slow
#2 if rsync isn't networking then -z is a waste of time
On 7/12/19 4:56 AM, Hannes Hutmacher via rsync wrote:
> Hi all! :-)
>
> I have a
Usually it means that the file changed while rsync was running. But it
can also mean that a hardware problem (usually RAM) is causing the
hashing to return bogus results.
On 6/3/19 6:09 AM, sambalist--- via rsync wrote:
> Hi there!
>
> On a daily backup script, I am getting a lot of these
--files-from will delete files from the destination that are listed but
not existing in the source. It isn't delete what isn't listed.
On 4/23/19 5:29 AM, MI via rsync wrote:
> I'm generating a list of files to sync, and would like all the files not
> in my list to be deleted from the
Having dry-run not act like the same command without --dry-run would
make less sense than people occasionally running it and discovering that
they need more options.
-v doesn't show things it didn't touch. So, it touched them for some
reason. Without --itemize-changes you are left in the dark
It doesn't seem like the trailing / on the target should matter. It
only means something special on the source.
However, if there is any error then rsync will abort the deletions for
safety.
On 4/3/19 2:10 PM, lugarci1 via rsync wrote:
> Hi, I was trying to make a mirror backup of a folder in
It can't do what you want. The closest thing would be --compare-dest.
On 2/13/19 5:26 PM, Delian Krustev wrote:
> On Wednesday, February 13, 2019 11:29:44 AM EET Kevin Korb via rsync
> wrote:
>> With --backup in order to end up with 2 files it has to write out a
>> whole
With --backup in order to end up with 2 files it has to write out a
whole new file. Sure, it only sent the differences (normally that means
over the network but there is no network here) but the writing end was
told to duplicate the file being updated before updating it.
On 2/13/19 10:47 AM,
I don't remember your original question but if I didn't suggest looking
at rrsync I should have. It comes with rsync in the contrib dir and it
knows which options to allow/deny and it can restrict the transfer to a
specific dir and read-only or write-only. Since it comes with rsync it
is kept
It does normally take some time to analyze large trees of files. It has
to call stat() on each file to get the size and timestamp.
However, 15 hours seems a bit excessive even though I have never tried
to do this on Windows or a NAS system. Just to be clear, is your
--link-dest parameter a
I can't say I have any idea why rsync would just skip that step and I
can't duplicate it myself.
Your only recourse might be to use --inplace on that system.
On 12/31/18 12:33 PM, Heiko Schlittermann via rsync wrote:
> Kevin Korb via rsync (So 30 Dez 2018 23:56:44 CET):
>> I think
es in sync ?
>
> maybe these links are interesting in that context:
>
> https://lists.samba.org/archive/rsync/2010-June/025164.html
>
> https://github.com/dop251/diskrsync
>
> roland
>
>> Gesendet: Sonntag, 30. Dezember 2018 um 19:53 Uhr
>> Von: "Kevin Korb
There have been addons to rsync in the past to do that but rsync really
isn't the correct tool for the job. Neither is dd.
The right tool is something that understands the filesystem within the
block device such as ntfsclone (what I use) or partimage (if you have
ever used Clonezilla this is
/tmp/Maildir/new/1546157908.1392_1.jidanni7
Also, don't use -z on a local copy. Rsync is dumb enough to do what you
tell it to.
On 12/30/18 3:40 AM, 積丹尼 Dan Jacobson via rsync wrote:
> Try as we may (--dry-run), it still won't tell us where it intends to put the
> files,
>
> $ rsync --dry-run
You need to switch to filters where you have the additional options
hide, show, risk, and protect. See the filter rules section of man rsync.
On 12/4/18 8:36 AM, Fabian Cenedese via rsync wrote:
> Hello
>
> I'm looking for a way to exclude and delete some items but not delete
> other items. Use
1 - 100 of 174 matches
Mail list logo
