On 16.11.2014 18:38, Karl O. Pinc wrote:
On 11/16/2014 03:53:12 PM, Joe wrote:
I have a lot of files (and directories) (up to a few hundred at a
time)
that I get from various sources. Some time after I get them (after
they
are already backed up), I often have to move them around and
I'm going to have to digest this for awhile. It makes sense, but I have
to work on it a bit before I understand it enough to actually apply it.
This would make a good howto article.
Thanks to both of you.
On 11/17/2014 04:56 AM, Matthias Schniedermeyer wrote:
On 16.11.2014 18:38, Karl O. Pinc
I have a lot of files (and directories) (up to a few hundred at a time)
that I get from various sources. Some time after I get them (after they
are already backed up), I often have to move them around and normalize
their names.
When I do this, rsync sees them as unrelated to the copies of these
On 11/16/2014 03:53:12 PM, Joe wrote:
I have a lot of files (and directories) (up to a few hundred at a
time)
that I get from various sources. Some time after I get them (after
they
are already backed up), I often have to move them around and
normalize
their names.
When I do this, rsync
Great idea which I will keep in mind for other cases!
In this case, however, the backups are on separate partitions on
external USB drives (I have a notebook), so hard links won't work.
Joe
On 11/16/2014 07:38 PM, Karl O. Pinc wrote:
On 11/16/2014 03:53:12 PM, Joe wrote:
I have a lot of files
The backups can be on separate partitions. What must be on one partition is
the file and it's hard link.
On November 16, 2014 6:58:26 PM CST, Joe jose...@main.nc.us wrote:
Great idea which I will keep in mind for other cases!
In this case, however, the backups are on separate partitions on
Hi,
I'm trying to get the --fuzzy option to work with --compare-dest with rsync
3.1.0.
I'm testing with two files. C_VOL-b001-i3818.spi and
C_VOL-b001-i3816.spi are copies of one another, but I've modified the
latter a bit with a hex editor as a test. The modified date is still the
same.
This
On Sat, Jun 11, 2005 at 02:05:48PM -0400, Erik Jan Tromp wrote:
#0 0x08060566 in flist_find ()
#1 0x0804c6cd in recv_generator ()
OK, the crash turned out to be caused by an empty file-list not getting
its high value set correctly. If such an empty list gets passed to
flist_find(), it would
On Sat, 11 Jun 2005 23:22:39 -0700
Wayne Davison [EMAIL PROTECTED] wrote:
OK, the crash turned out to be caused by an empty file-list not getting
its high value set correctly. If such an empty list gets passed to
flist_find(), it would crash. This is not something that normally
happens, but
On Fri, Jun 10, 2005 at 05:14:57AM -0400, Erik Jan Tromp wrote:
if I remove every possible option except --fuzzy --link-dest,
segfault every time.
I haven't seen that in my testing. One easy thing to do is to make sure
that core dumping is enabled and look at a backtrace:
ulimit -c unlimited
On Sat, 11 Jun 2005 09:03:07 -0700
Wayne Davison [EMAIL PROTECTED] wrote:
On Fri, Jun 10, 2005 at 05:14:57AM -0400, Erik Jan Tromp wrote:
if I remove every possible option except --fuzzy --link-dest,
segfault every time.
I haven't seen that in my testing. One easy thing to do is to make
I've been reworking my backup script decided to give some of the newer
options a try. It would appear I've found a combination that doesn't play nice.
$ rsync --archive --delete-during --fuzzy --hard-links --numeric-ids
--quiet --sparse --temp-dir /backup/helium/
--link-dest
12 matches
Mail list logo
