On 11/29/2014 03:54 PM, Nikolaus Rath wrote:
> 2. fsck.s3ql not being able to fix the local database
This one is more interesting. The traceback looks as if the backend (aka
S3) reports two objects with the same name (which I think should be
impossible). Since S3QL is using the object names as primary keys in a
table, this does not end well.
Could you apply the attached patch to /usr/lib/s3ql/s3ql/fsck.py and
check the original file system again (i.e., not the copy)?
It should crash at the same point as before, but create a file
"object_list.txt" in the current directory. Please attach that file to
this bug.
Thanks!
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
diff --git a/src/s3ql/fsck.py b/src/s3ql/fsck.py
--- a/src/s3ql/fsck.py
+++ b/src/s3ql/fsck.py
@@ -829,6 +829,9 @@
lof_id = self.conn.get_val("SELECT inode FROM contents_v "
"WHERE name=? AND parent_inode=?", (b"lost+found", ROOT_INODE))
+ # Debugging
+ debug_fh = open('object_list.txt', 'w')
+
# We use this table to keep track of the objects that we have seen
self.conn.execute("CREATE TEMP TABLE obj_ids (id INTEGER PRIMARY KEY)")
try:
@@ -838,6 +841,8 @@
sys.stdout.write('\r..processed %d objects so far..' % i)
sys.stdout.flush()
+ print(obj_name, file=debug_fh)
+
# We only bother with data objects
try:
obj_id = int(obj_name[10:])
