Backup Central

On 2 Nov 2005, at 01:25, Ben Escoto wrote:

4. The backup attempt eventually failed with a ___File name too
long___ error.

...

OSError: [Errno 63] File name too long: '/Volumes/Ext_BU/Users/kwh/


Assuming you were updating a backup started earlier, this is a good
sign, since for backwards compatibility it needs to keep quoting if
quoting was enabled before. However, filename too long errors should
be recoverable, and not crash rdiff-backup. Perhaps you could start
the python interpreter and type this in:


import errno
errno.ENAMETOOLONG

36

errno.errorcode[63]

'ENOSR'

(example values are what my system says---yours must be different if
it is crashing rdiff-backup).

I get:

% python
Python 2.4.2 (#1, Oct 14 2005, 16:33:25)
[GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
import errno
errno.ENAMETOOLONG
63
errno.errorcode[63]
'ENAMETOOLONG'

Kevin

Kevin Horton <khorton01 < at > rogers.com>
wrote the following on Wed, 2 Nov 2005 05:06:11 -0500
On 2 Nov 2005, at 01:25, Ben Escoto wrote:

4. The backup attempt eventually failed with a ___File name too
long___ error.

This should be fixed in version 1.1.1.


--
Ben Escoto

On 5 Nov 2005, at 23:59, Ben Escoto wrote:

Kevin Horton <khorton01 < at > rogers.com>
wrote the following on Wed, 2 Nov 2005 05:06:11 -0500
On 2 Nov 2005, at 01:25, Ben Escoto wrote:

4. The backup attempt eventually failed with a ___File name too
long___ error.

This should be fixed in version 1.1.1.


I put the offending file back where it was when it caused the error,
and tried a backup using version 1.1.2. The file with the long name
was correctly backed up, and I opened it to be sure everything was OK.

This problem appears to be fixed.

I'm making a fresh backup with carbonfile enabled, and I will report
back once I have done some testing.

Kevin Horton