Backup Central

I've validated (via running pdb and looking at the actual file handle
the call is being made on) that it's a directory being fsync'd. However,
this still happens even if I munge Globals.py and force
Globals.fsync_directories to 0.

This is happening on a separate pair of systems from those mentioned in
my last email. The more interesting bits are near the bottom; feel free
to skip down.

On the client:

# rdiff-backup --check-destination-dir --remote-schema 'netcat %s
10873' 10.1.128.1::/backup
Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py",
line 286, in Main
take_action(rps)
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py",
line 258, in take_action
elif action == "check-destination-dir": CheckDest(rps[0])
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py",
line 862, in CheckDest
dest_rp.conn.regress.Regress(dest_rp)
File
"/usr/lib64/python2.3/site-packages/rdiff_backup/connection.py",
line 445, in __call__
return apply(self.connection.reval, (self.name,) + args)
File
"/usr/lib64/python2.3/site-packages/rdiff_backup/connection.py",
line 367, in reval
if isinstance(result, Exception): raise result
OSError: [Errno 22] Invalid argument

On the server, session spawned by the above client:

Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py",
line 286, in Main
take_action(rps)
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py",
line 254, in take_action
connection.PipeConnection(sys.stdin, sys.stdout).Server()
File
"/usr/lib64/python2.3/site-packages/rdiff_backup/connection.py",
line 352, in Server
self.get_response(-1)
File
"/usr/lib64/python2.3/site-packages/rdiff_backup/connection.py",
line 314, in get_response
try: req_num, object = self._get()
File
"/usr/lib64/python2.3/site-packages/rdiff_backup/connection.py",
line 230, in _get
raise ConnectionReadError("Truncated header string (problem "
rdiff_backup.connection.ConnectionReadError: Truncated header string
(problem probably originated remotely)

On the server, running locally:

Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py",
line 286, in Main
take_action(rps)
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py",
line 258, in take_action
elif action == "check-destination-dir": CheckDest(rps[0])
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py",
line 862, in CheckDest
dest_rp.conn.regress.Regress(dest_rp)
File "/usr/lib64/python2.3/site-packages/rdiff_backup/regress.py",
line 70, in Regress
for rf in iterate_meta_rfs(mirror_rp, inc_rpath): ITR(rf.index, rf)
File
"/usr/lib64/python2.3/site-packages/rdiff_backup/rorpiter.py", line
285, in __call__
last_branch.fast_process(*args)
File "/usr/lib64/python2.3/site-packages/rdiff_backup/regress.py",
line 232, in fast_process
if rf.metadata_rorp.isreg(): self.restore_orig_regfile(rf)
File "/usr/lib64/python2.3/site-packages/rdiff_backup/regress.py",
line 262, in restore_orig_regfile
rf.mirror_rp.get_parent_rp().fsync() # require move before inc
delete
File "/usr/lib64/python2.3/site-packages/rdiff_backup/rpath.py",
line 1068, in fsync
if not fp: self.conn.rpath.RPath.fsync_local(self)
File "/usr/lib64/python2.3/site-packages/rdiff_backup/rpath.py",
line 1075, in fsync_local
os.fsync(fd)
OSError: [Errno 22] Invalid argument

While running with a high verbosity level, I typically see the results
of the filesystem tests -- but running locally with
--check-destination-dir, I don't see these tests being done. When they
*are* done, however, the results are as follows:

Detected abilities for destination (read/write) file system:
Characters needing quoting ''
Ownership changing On
Hard linking On
fsync() directories Off
Directory inc permissions On
High-bit permissions On
Access control lists Off
Extended attributes Off
Mac OS X style resource forks Off
Mac OS X Finder information Off

I'm guessing, then, that check-destination-dirs is trying to call fsync
on a directory despite lack of support for such on the filesystem in
question, because (for some reason) it isn't doing the tests. (At least,
I'm *presuming* it isn't doing the tests, because even with
terminal-verbosity >= 5 they aren't printed during a local
--check-destination-dir operation).