List, good morning,
We're in the middle of moving our backup destination from an old
machine (with only 2TB) to a new one with 6TB space; each of these is
on a separate NFS share mounted under /mnt. Our migration scheme is
straightforward, but we hit a problem, possibly with permissions, and
Could it be that perhaps the UID mapping is not set up correctly? Being
able to do r/w but not being able to preserve times and set permission
could indicate that somehow the NFS-Server thinks that the files are
not owned by the user issuing the command. Cam you do a chmod
manually? Or can it
On 15/04/2014 10:38, Claus-Justus Heine wrote:
Could it be that perhaps the UID mapping is not set up correctly? Being
able to do r/w but not being able to preserve times and set permission
could indicate that somehow the NFS-Server thinks that the files are
not owned by the user issuing the
Am 15.04.14 13:27, schrieb Ron Leach: Useful pointers, thank you. What
I find is that all the *directories*
under /mnt/exist-dest and /mnt/new-dest have the same permissions
(exactly as I had intended by using the -a parameter on the cp command
to copy the existing backups to the new machine),
Got following error, I am not familiar with troubleshooting with
rdiff-backup, can anyone suggest some way for me to troubleshoot ?
Thanks in advance.
SK
Previous backup seems to have failed, regressing destination now.
Exception 'Bad index order: ('long_filename_data', '1') = ('ctse',
Hey, I'm a new rdiff-backup user having some question on how to handle
errors.
First I'd like to point out that the link to the mailing list in
http://rdiff-backup.nongnu.org/savannah.html#mailing_list
is broken.
Now, the real question is that, I'm using inside a bash script for
backup a command
In all likelihood, your problem is caused by hardlinked files in
your backup. The --verify and --compare-hash directives in
version 1.2.8 have problems with such files.
You might take a look at bug report #26848:
https://savannah.nongnu.org/bugs/?26848
I have just now updated the report with
On 08/11/2010 08:03 PM, Robinson, Eric wrote:
I've never tried using --compare-hash.
There has been a lot of talk in the past about how to
verify backups and really for me the only full proof solution
is to restore somewhere and compare (diff) against original.
Unfortunately, I am talking
The rdiff-backup comparison should work if you're
using a recent rdiff-backup on both ends.
You mean the rdiff-backup version? It's 1.2.8 on both servers. But does
it to an in-place comparison? If I understand the man page correctly, it
first copies the data from the dest to the source and
On 08/12/2010 03:55 PM, Robinson, Eric wrote:
You mean the rdiff-backup version? It's 1.2.8 on both servers. But does
it to an in-place comparison? If I understand the man page correctly, it
first copies the data from the dest to the source and then compares it
there?
I'm also running 1.2.8 on
I think you misunderstood the man page (if you're
talking about what it says for --compare-hash).
I was talking about using compare-full as an alternative to
compare-hash. I believe the man page states that compare-full brings the
whole file over from the dest to the source and compares it
]
On Behalf Of Robinson, Eric
Sent: Saturday, August 07, 2010 8:50 AM
To: rdiff-backup-users@nongnu.org
Subject: [rdiff-backup-users] Error Unable to compare BUT THEN No
changesfound. Directory matches. What?
I've been using rdiff-backup for a while, but today was the first time I
tried using
Of Robinson, Eric
Sent: Saturday, August 07, 2010 8:50 AM
To: rdiff-backup-users@nongnu.org
Subject: [rdiff-backup-users] Error Unable to compare BUT THEN No
changesfound. Directory matches. What?
I've been using rdiff-backup for a while, but today was the first time I
tried using
I've never tried using --compare-hash.
There has been a lot of talk in the past about how to
verify backups and really for me the only full proof solution
is to restore somewhere and compare (diff) against original.
Unfortunately, I am talking about directories with up to 2 million files
, August 07, 2010 8:50 AM
To: rdiff-backup-users@nongnu.org
Subject: [rdiff-backup-users] Error Unable to compare BUT THEN No
changesfound. Directory matches. What?
I've been using rdiff-backup for a while, but today was the first time I
tried using the --compare-hash directive.
First I get tons
+eric.robinson=psmnv@nongnu.org
[mailto:rdiff-backup-users-bounces+eric.robinson=psmnv@nongnu.org]
On Behalf Of Robinson, Eric
Sent: Saturday, August 07, 2010 8:50 AM
To: rdiff-backup-users@nongnu.org
Subject: [rdiff-backup-users] Error Unable to compare BUT THEN No
changesfound. Directory
I've been using rdiff-backup for a while, but today was the first time I
tried using the --compare-hash directive.
First I get tons of these messages...
Warning: Metadata file has no digest for file, unable to
compare.
That's scary enough by itself. But then at the end it says...
Hi again,
To follow up on this:
The backup was unfortunately lost, as has always happened before when
these problems occurred.
However with Andreas' help, we got more information as to what happened.
The original problem was triggered by a monster file that was too big to
copy to the backup.
Hi,
I'm again having a problem with the old issue of having rdiff-backup
forget a file that was accidentally backed up.
I double checked the FAQ and Wiki, but there really isn't a solution yet.
It would be very good to have an official means of solving these problems.
There was a discussion
Hello,
The package names required are python-devel and librsync-devel
+--
|This was sent by kooln...@gmail.com via Backup Central.
|Forward SPAM to ab...@backupcentral.com.
On Tue, Sep 22, 2009 at 5:55 PM, prateekmoturi
rdiff-backup-fo...@backupcentral.com wrote:
Hi i am getting the following error messages when i am trying to backup.
I am using the rdiff-backup 1.2.8.
Can anyone please help me to find the solution for the following error...
IOError: CRC check
prateekmoturi wrote:
Hi i am getting the following error messages when i am trying to backup.
I am using the rdiff-backup 1.2.8.
Can anyone please help me to find the solution for the following error...
Traceback (most recent call last):
File /usr/bin/rdiff-backup, line 30, in ?
Hi i am getting the following error messages when i am trying to backup.
I am using the rdiff-backup 1.2.8.
Can anyone please help me to find the solution for the following error...
Traceback (most recent call last):
File /usr/bin/rdiff-backup, line 30, in ?
I'm getting this error again. Last time I got it, I started a new
repository.
But it's back...
Here's a -v 6 listing around the error.
---
Processing changed file Shared-docs/Abc/Jiff's Document Info.1234.QBW.nd
Regular copying ('Shared-docs', 'Abc', Jiff's Document Info.1234.QBW.nd) to
My guess would be that the file is open, but Windows has several
different ways of locking a file open and then being nasty to other
programs trying to use it --
- The way the registry .DAT file is kept open while a user is logged in
-- makes the file totally inaccessible to anything, error
Hi all:
I have an Ubuntu 8.10 system with rdiff v1.1.16 installed. Using the
recipe on the wiki:
http://wiki.rdiff-backup.org/wiki/index.php/Installations#Concurrent_installation_of_different_versions_of_rdiff-backup
and making the appropriate changes to the version number, I got an error
Hi Josh:
Thanks for the suggestion. I installed python-dev (curious: why was this
not installed as part of the original v1.1.16 installation?), re-ran the
'build' cmd. - it errored out so I rm-r the build dir. and tried again.
It works until:
snip
building 'rdiff_backup._librsync' extension
got it. needed librsync-dev as well. still curious as to why these two
packages weren't already installed with v1.1.16?
Thanks,
~bob
Bob Mead wrote:
Hi Josh:
Thanks for the suggestion. I installed python-dev (curious: why was
this not installed as part of the original v1.1.16
The reason that those packages weren't needed before is that (IIUC) you
installed the binary packages. It was only once you tried to build
rdiff-backup from source that you needed the development files for
python and librsync.
JoshN
Bob Mead wrote:
got it. needed librsync-dev as well. still
Thanks Josh. I've updated the wiki page to add this information.
~bob
Josh Nisly wrote:
The reason that those packages weren't needed before is that (IIUC)
you installed the binary packages. It was only once you tried to build
rdiff-backup from source that you needed the development files
Well I managed to get SMB access working somehow. A combination of
unix extensions = no in the global space of my samba configuration,
building the proper driver for my NIC on the linux server, and luck.
I also got netatalk setup and running for AFP access, and installed
rdiff-backup on
Hi Nathan,
Thanks so much for doing the testing. I had not expected those
results. Of course, the more interesting test is when you do a backup
in which there are dozens of changes scattered across the files. That
is where the rsync algorithm is supposed to be helpful -- it trades
Hi Andrew,
Sorry for the delay. I tried to run it with 1.3.3 and here's what I
got:
HotPlate:~ nathan$ rdiff-backup -v 5 ~/Desktop/ /Volumes/Insurance/
Backup/
Using rdiff-backup version 1.3.3
Unable to import module posix1e from pylibacl package.
POSIX ACLs not supported on filesystem at
On Mar 29, 2009, at 12:33 PM, Nathan Aschbacher wrote:
The rm tgt fails, well not exactly. It runs without an error the
first time, but some kind of problem occurs on OS X where the file
won't stay deleted, it immediately reappears. Once it reappears two
problems occur. First, if you
On Mar 20, 2009, at 6:44 PM, Nathan Aschbacher wrote:
I've tried several versions of rdiff-backup (up through 1.3.3) and
several versions of Python (up through 2.6.1). I believe the issues
relates to symbolic links based on the error. It seems to fail when
doing its destination
I've tried several versions of rdiff-backup (up through 1.3.3) and
several versions of Python (up through 2.6.1). I believe the issues
relates to symbolic links based on the error. It seems to fail when
doing its destination capability tests when it fails to delete the
temp symlink.
I've tried several versions of rdiff-backup (up through 1.3.3) and
several versions of Python (up through 2.6.1). I believe the issues
relates to symbolic links based on the error. It seems to fail when
doing its destination capability tests when it fails to delete the
temp symlink.
I've tried several versions of rdiff-backup (up through 1.3.3) and
several versions of Python (up through 2.6.1). I believe the issues
relates to symbolic links based on the error. It seems to fail when
doing its destination capability tests when it fails to delete the
temp symlink.
On Mar 20, 2009, at 6:44 PM, Nathan Aschbacher wrote:
I've tried several versions of rdiff-backup (up through 1.3.3) and
several versions of Python (up through 2.6.1). I believe the issues
relates to symbolic links based on the error. It seems to fail when
doing its destination
weird -- the ls command on 10.4.11 doesnt have the -@ switch... so i
attempted to use rsync 3 with the -X switchto transfer and got the same
error:
sending incremental file list
rsync: get_xattr_names: llistxattr(duraseal/RequestADemo.html,1024)
failed: Invalid argument (22)
rsync:
hi there..
just installed rdiff-backup on a couple machines (one on server 10.5.6
python 2.5.1 and one on server 10.4.11 python 2.3) -- everything
worked fine upon first backup - but is throwing some errors on 4 files
upon subsequent ones. nothing too crazy with the setup that i am
Hi Sphen,
Strange error ... Each time, it comes when rdiff-backup is asking for
a list of the extended attributes on those 4 files.
What does `file` and `ls -...@e` report on each of those files?
/Library/WebServer/Documents/duraseal/Comps/index.psd
Andrew Ferguson wrote:
On Jan 5, 2009, at 6:06 AM, Dominic wrote:
... but I do get an error
with rdiff-backup 1.2.4 when running from a *Windows* client (to
Linux-based rdiff-backup server) thus:
C:\rdiff-backup -r 0D
On Jan 5, 2009, at 6:06 AM, Dominic wrote:
... but I do get an error with rdiff-backup 1.2.4 when running from
a *Windows* client (to Linux-based rdiff-backup server) thus:
C:\rdiff-backup -r 0D dominic-pcchi...@192.168.100.125::archives/
mydocs/myfile.docx myfile.docx
Traceback (most
... but I do get an error with rdiff-backup 1.2.4 when running from a
*Windows* client (to Linux-based rdiff-backup server) thus:
C:\rdiff-backup -r 0D dominic-pcchi...@192.168.100.125::archives/mydocs/myfile.docx myfile.docx
Traceback (most recent call last):
File "rdiff-backup", line 30,
Experimenting with restoring files I have hit an error and I hope
someone can help me. Running on the local backup machine this restore
works fine:
rdiff-backup -r 0D /home/dominic-pcchips2/archives/mydocs/To Do.xlsx
~/To Do.xlsx
but when I try to restore by running from a remote Linux
wrote:
On Jan 1, 2009, at 5:58 AM, Dominic wrote:
Experimenting with restoring files I have hit an error and I hope
someone can help me. Running on the local backup machine this restore
works fine:
rdiff-backup -r 0D /home/dominic-pcchips2/archives/mydocs/To
Do.xlsx ~/To Do.xlsx
but when
I am experiencing the following error with 1.2.1. Any thoughts on how to
fix it?
Previous backup seems to have failed, regressing destination now.
Exception 'RPath instance has no attribute 'inc_compressed'' raised of class
+'type 'exceptions.AttributeError'':
File
I am experiencing the following error with 1.2.1. Any thoughts on how to
fix it?
Previous backup seems to have failed, regressing destination now.
Exception 'RPath instance has no attribute 'inc_compressed'' raised of class
+'type 'exceptions.AttributeError'':
File
Hi All,
I am very thankfull to you to provide me such support and guidence.
I am using rdiff-backup on windowsXP and on windows Vista using cygwin.
I can get the backups and restore it by running Cygwin.bat it is in C:\Cygwin\
folder. Or I can do the same by running bash.exe file it is in
Hello,
Wilson Azevedo a écrit :
Friends rdiff-backup's users
I'm a Linux (Xandros Debian Etch, on an Asus EeePC) novice user and
need help to upgrade rdiff-backup to version 1.1.6 or 1.1.7. The
version 1.1.5 I've installed from debian.org repository has a bug in
working with Samba mounted
`As 10:51 AM 2/27/2008, gart algar disse:
add the following line :
deb http://www.backports.org/debian etch-backports main contrib non-free
Gart,
Thank you very much. But when I've checked this repository I've found
a 1.1.14 version -- older than 1.1.5 that I've installed from
debian-etch
Friends rdiff-backup's users
I'm a Linux (Xandros Debian Etch, on an Asus EeePC) novice user and
need help to upgrade rdiff-backup to version 1.1.6 or 1.1.7. The
version 1.1.5 I've installed from debian.org repository has a bug in
working with Samba mounted windows file systems as well as sshfs
Iain Dooley wrote:
hi all, i've been running rdiff-backup for about a year and a half with no
troubles. i use version 1.1.5 on freebsd 6.2R.
yesterday on two of my systems, i got the error below. other systems are
still running correctly.
socata# /root/backup.sh
File
hi all, i've been running rdiff-backup for about a year and a half with no
troubles. i use version 1.1.5 on freebsd 6.2R.
yesterday on two of my systems, i got the error below. other systems are
still running correctly.
i can't find anything meaningful in the messages below, does anyone else
Mario Doering wrote:
Regressing file scripts/AddrDat.dll Exception '[Errno 22] Invalid
argument' raised of class 'exceptions.OSError': File
/usr/lib64/python2.4/site-packages/rdiff_backup/Main.py, line 302, in
error_check_Main try: Main(arglist) File
Hello,
I get an error with File name too long. I can correct it on the source
by removing the too-long file, but the destination still give me an
error (see attached files below) and rdiff-backup crashs.
How can I remove this error ?
system infos :
nas03:~# rdiff-backup --version
rdiff-backup
[same message but with the attachement now :) sorry]
Hello,
I get an error with File name too long. I can correct it on the source
by removing the too-long file, but the destination still give me an
error (see attached files below) and rdiff-backup crashs.
How can I remove this error ?
system
Hello :-)
I get the following error using rdiff-backup 1.1.14 on cifs mounted
share.
What other information can I offer? Or what obvious error did I make? :D
rdiff-backup -v 5
--check-destination-dir /mnt/backup_local/daehne/Inetpub Using
rdiff-backup version 1.1.14 Warning: hard linking not
On 9/6/07, Mario Doering [EMAIL PROTECTED] wrote:
Hello :-)
I get the following error using rdiff-backup 1.1.14 on cifs mounted
share.
What other information can I offer? Or what obvious error did I make? :D
Your problem as far as I can tell, is trying to use a cifs mount as a
rdiff-backup
On Thu, 6 Sep 2007 12:06:46 +0200
David [EMAIL PROTECTED] wrote:
I think that your rdiff-backup is failing because it detects a failed
earlier rdiff-backup session and wants to regress to before that
failed backup. But the regress fails because rdiff-backup is unable to
set the permissions
The check command results in the same error as the
check-destination-dir.
Oops, I meant '--check-destination-dir', not '--check'. There is no
'--check' rdiff-backup option, but rdiff-backup is clever enough to
see you really wanted to use '--check-destination-dir'
rdiff-backup is started
rdiff-backup is started locally. I cannot install nfs on that machine,
but I can rsync all the stuff to another directory (ext3) and run the
check command there.
I'll report back then :)
yes.. when copied to an ext3 filesystem, the check command works.
So the rdiff error has something to
rdiff-backup is started locally.
Not sure if we're missing each other. When I said log into the remote
machine and run rdiff-backup locally, I meant locally on the other
machine.
ie:
1) ssh $REMOTEHOST
2) rdiff-backup -v 5 --check-destination-dir $DESTINATION_DIR
rdiff-backup
Mario Doering wrote:
@rdiff-backup crew:
Is this info enough for the coders to know where the problem is located?
I think it might be.
What kernel version are you running on your own system and on the server?
Andrew
--
Andrew Ferguson - [EMAIL PROTECTED]
You mean locally on the computer which contains the backup-up files
(including riff-backup-data) shared via samba?
Yes that's what I meant.
If yes, a login there is not possible. It is a terastation (=black
box) with only access via cifs.
So your backup involves pushing to the terastation
On Thu, 06 Sep 2007 09:54:20 -0400
Andrew Ferguson [EMAIL PROTECTED] wrote:
What kernel version are you running on your own system and on the
server?
I could reproduce this problem on the following kernels that mount the
cifs share:
2.6.20-xen-r1
and
2.6.14-gentoo-r4
The kernel on the
On Thu, 6 Sep 2007 16:19:03 +0200
David [EMAIL PROTECTED] wrote:
If yes, a login there is not possible. It is a terastation (=black
box) with only access via cifs.
So your backup involves pushing to the terastation
And this share is mounted on the linux system running rdiff-backup
SOULfly_B wrote:
It seems this issue is not fixed cause I still have the problem.
Attached is an extract of the traceback.
Hi Bruno,
You have picked up a very interesting bug, which was introduced in
1.1.8. When you first sent your report, I had only looked at the changes
I had made.
For
Bruno Spyckerelle wrote:
I've updated rdiff-backup from 1.1.7 to 1.1.12 and i've now a bug with a
directory containing an accented letter.
The backup is done using a samba share mounted with the following command :
smbmount //IP/dir /home/$DIR -o username=admin,rw
Hi Bruno,
This bug is
This bug was fixed in CVS and will be part of next release: 1.1.13
If you want to fix it now, add 'EOPNOTSUPP' to the list of error codes
that starts around line 54 in robust.py. It's a big list in the function
catch_error(exc) ... you can't miss it
Thanks. Now it proceeds further and
Vytautas Stankevičius wrote:
This bug was fixed in CVS and will be part of next release: 1.1.13
If you want to fix it now, add 'EOPNOTSUPP' to the list of error codes
that starts around line 54 in robust.py. It's a big list in the function
catch_error(exc) ... you can't miss it
Thanks.
Yes, that was the problem.
Now i am with version 1.1.5 im both servers but i get this error:
Exception '' raised of class 'exceptions.AssertionError':
File /usr/lib/python2.3/site-packages/rdiff_backup/Main.py, line 295, in
error_check_Main
try: Main(arglist)
File
Marcelo Diotto wrote:
But i always get this error:
Exception 'too many values to unpack' raised of class
Marcelo,
You are not using the same version of rdiff-backup on both sides.
An important change was made to the network protocol in 1.1.12 to fix a
long-standing bug. If you use 1.1.12 on
Hello Everybody,
I'm trying to do the following command:
# rdiff-backup / alpha::/raid/marte
But i always get this error:
Exception 'too many values to unpack' raised of class 'exceptions.ValueError
':
File /usr/lib/python2.3/site-packages/rdiff_backup/Main.py, line 299, in
error_check_Main
Marcelo Diotto wrote:
Yes, that was the problem.
Now i am with version 1.1.5 im both servers but i get this error:
Exception '' raised of class 'exceptions.AssertionError':
I believe this is one of the bugs fixed after 1.1.5. Please don't use
earlier development versions. The latest one is
- Original Message -
From: Thibaud Hulin [EMAIL PROTECTED]
To: rdiff-backup-users@nongnu.org
Sent: Friday, January 19, 2007 5:44 PM
Subject: [rdiff-backup-users] error : af_unix path too long
Hello !
Thanks for your good work with rdiff_backup !
I have a problem, when I lanuch rdiff
Hello everyone,
when trying to invoke rdiff-backup in the most simple way (e.g.
rdiff-backup /home/myhomedir /media/myremoteharddrive), I get an error
with a less than obvious cause (at least for me):
=
Exception '[Errno 22]
Hi Devraj,
how are you mounting the NAS device?
dave
Devraj Mukherjee wrote:
Hi everyone,
I am trying to use rdiff-backup to write to an NAS device and this is
wha tI get.
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
Hi everyone,
I am trying to use rdiff-backup to write to an NAS device and this is
wha tI get.
Any ideas?
[EMAIL PROTECTED] ~]# rdiff-backup /www/apache2 /mnt/nas/www/apache2
Warning: ownership cannot be changed on filesystem at
/mnt/nas/www/apache2/rdiff-backup-data
Warning: hard linking not
I'm running rdiff-backup 0.12.8, because the system I'm backing up is
pretty ancient and I just haven't been motivated to upgrade it yet. A
while back, one of my backups was interrupted, so the next time it ran
rdiff-backup had to regress the archive, and encountered an error:
Previous backup
On Sun, 21 May 2006, Randall Nortman wrote:
I'm not sure where to look for this in the metadata.
look in the mirror_metadata file in the rdiff-backup-data subdirectory of
the target... you could probably gunzip and edit away the entry for that
file.
i think this one is fixed by later revs,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben Escoto wrote:
Jim St.Cyr [EMAIL PROTECTED]
wrote the following on Sun, 29 Jan 2006 19:56:38 -0500
I've been using the 1.1.5 version for a while now. Is there any way to
start writing the hashes or to verify that they are being written at
Jim St.Cyr [EMAIL PROTECTED]
wrote the following on Wed, 25 Jan 2006 12:53:43 -0500
I get an error message similiar to the following:
Hash for Docs/WAN Policy 10.2.doc missing, cannot check
A Google search has unearthed where the error message in the code is
originating from but I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben Escoto wrote:
Jim St.Cyr [EMAIL PROTECTED]
wrote the following on Wed, 25 Jan 2006 12:53:43 -0500
I get an error message similiar to the following:
Hash for Docs/WAN Policy 10.2.doc missing, cannot check
A Google search has unearthed where
Jim St.Cyr [EMAIL PROTECTED]
wrote the following on Sun, 29 Jan 2006 19:56:38 -0500
I've been using the 1.1.5 version for a while now. Is there any way to
start writing the hashes or to verify that they are being written at
all? More important, am I stuck or should I downrev to an earlier
Hello-
I've been backing up a directory using the command:
/usr/bin/rdiff-backup --print-statistics /mnt/server5b_e$/Users/Common/IRM_Common /raid5/backup/server5b/IRM_Users
I'm attempting to recover a subdirectory using the command:
rdiff-backup -r 4D --force
Ok, some more on this bug. It seems rsync-backup successfully completes
the backup, but still generates this error. I compared the MD5 sums of
both the original file and the backup and they are identical.
I added the complete backtrace of the error here:
python: ERROR: (rs_job_iter) internal
Gerard van Dijnsen [EMAIL PROTECTED]
wrote the following on Fri, 13 Jan 2006 22:08:26 +0100
Ok, some more on this bug. It seems rsync-backup successfully completes
the backup, but still generates this error. I compared the MD5 sums of
both the original file and the backup and they are
Hi all,
Using rdiff-backup with some large files (4 Gb) I get the following error:
UpdateError filename librsync error 107 while in patch cycle
Googling around I found out that it may be an error with librsync 9.7. Can you
confirm this? And does a patch exist?
Regards,
Gerard
Okay thanks.. well I saw that error, but it didn't mean anything to me,
but I guess that's because I didn't read it.
The weird thing is that I reran the backup manually and that fixed it
with no --check-backup-dir directory.. but when it did run, it did a lot
of unusual things like deleting
I have a server being backed up by rdiff-backup, and occasionally the
backup fails for network or other reasons. The problem I am experiencing
happens on the _next_ backup. The command issued is:
--
rdiff-backup
Keith Edmunds [EMAIL PROTECTED]
wrote the following on Thu, 08 Sep 2005 08:46:28 +0100
--
Warning: Could not restore file /backups/yyy/xxx/02LaidOut/.DS_Store!
A regular file was indicated by the metadata, but could not be
-
Detected abilities for source (read only) file system:
Extended attributes On
...
Detected abilities for destination (read/write) file system:
Extended attributes
94 matches
Mail list logo
