rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] "Solution" for the NFS related problems with rm


From: Ben Escoto
Subject: Re: [rdiff-backup-users] "Solution" for the NFS related problems with rmdir()
Date: Tue, 27 Jan 2004 20:16:17 -0800

>>>>> Antoine Perdaens <address@hidden>
>>>>> wrote the following on Sat, 13 Dec 2003 19:44:22 +0100

> I'm wondering if it is enough and why it isn't by default, the change 
> is made in rpath.py and consist in:
> 
>          def rmdir(self):
>                  log.Log("Removing directory " + self.path, 6)
>                  #self.conn.os.rmdir(self.path)
>                  try: self.conn.os.rmdir(self.path)
>                  except os.error: shutil.rmtree(self.path)
>                  self.data = {'type': None}
> 
> It fixes the problems I had with NFS mounted disks...

Thanks, that seems like a useful workaround.  You may want to add it
as a patch to Savannah or the rdiff-backup wiki.

However, the "directory not empty" error seems to be a symptom of the
general problem that operations are happening out of order.
rdiff-backup depends on the order of operations, not just when
deleting a directory, but also to make sure things are in a consistent
state.

I just had a thought, would it work to fsync the directory?  As in
something like:

          def rmdir(self):
                  log.Log("Removing directory " + self.path, 6)
                  #self.conn.os.rmdir(self.path)
                  try: self.conn.os.rmdir(self.path)
                  except os.error:
                        self.fsync()
                        self.conn.os.rmdir(self.path)
                  self.data = {'type': None}

If that works I would check it in, because rdiff-backup should use
fsync whenever it really needs things to happen in a certain order.
(Deleting a directory is a special case, there the commands should
make it clear to the OS that things have to happen in order, so no
fsync is normally needed.)


-- 
Ben Escoto




reply via email to

[Prev in Thread] Current Thread [Next in Thread]