[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] bug/crash on read-only file in incremental back
Re: [rdiff-backup-users] bug/crash on read-only file in incremental backup
Fri, 14 Nov 2008 17:33:26 -0600
Thunderbird 188.8.131.52 (X11/20080925)
Attached is a patch that fixes the problem for me. I get a slightly
different traceback than was reported by others, but this is the correct
solution. The problem is that Windows does not allow deletion of
read-only files. This patch simply removes the readonly flag before
removing the file. (This is the same behavior as Windows Explorer.)
Andrew Ferguson wrote:
You may or may not find this patch helpful when you are working on the
read-only files. This is my patch to support filesystem flags like
'immutable' or 'secure delete' ... obviously when flags like
'immutable' are set, it becomes important to unset it as necessary.
Follow the placement of the "make_fsflags_mutable" calls.
I never incorporated this patch into CVS because 1) it needed to
switch to having tests in fs_abilities and 2) I needed to figure how
to detect support for chflags(2) -- I think Python 2.6 added chflags()
support, but I'll have to double-check.
I suppose another piece of advice would be to watch for the places
where chmod() is called directly in the current rdiff-backup -- things
like chmod(0700 | file.perms()) are a good bet for places where we
need to adjust the permissions to make the backup work.
On Nov 14, 2008, at 11:26 AM, Josh Nisly wrote:
I was planning on fixing this. Are you already working on it? If not,
I'll try to send a patch in the next day or two.
Andrew Ferguson wrote:
On Nov 14, 2008, at 8:18 AM, Philip Warner wrote:
On windows, I get the following crash when doing an incremental on a
file that is read-only, but which has been updated.
Googling produced the only other reference:
which went unanswered.
Thank you for bringing this issue up again. Somehow, I missed the
I'll work on fixing this bug for the next release. On Unix, I
believe rdiff-backup generally handles this situation correctly.
From your traceback, it is clear that Windows returns
Windows-specific error codes in this instance, which rdiff-backup
was unprepared to handle.
rdiff-backup-users mailing list at address@hidden
--- rdiff_backup/rpath.py 12 Oct 2008 02:21:30 -0000 1.131
+++ rdiff_backup/rpath.py 14 Nov 2008 23:25:55 -0000
@@ -253,11 +253,13 @@
except OSError, error:
- if error.errno != errno.EEXIST: raise
+ if error.errno != errno.EEXIST and \
+ error.errno != errno.EPERM: raise
# On Windows, files can't be renamed on top of
an existing file
+ rp_source.conn.os.chmod(rp_dest.path, 0700)
@@ -1052,7 +1054,15 @@
if Globals.fsync_directories: self.fsync()
- else: self.conn.os.unlink(self.path)
+ try: self.conn.os.unlink(self.path)
+ except OSError, error:
+ if error.errno == errno.EPERM:
+ # On Windows, read-only files
cannot be deleted.
+ # Remove the read-only
attribute and try again.