attic icon indicating copy to clipboard operation
attic copied to clipboard

Error while creating backup - 'Repository' object has no attribute 'segments'

Open shrx opened this issue 10 years ago • 15 comments

I have initialized attic with

attic init kanta.attic

and then wanted to create a backup with

sudo attic create kanta.attic::backup-$(date +%Y-%m-%d) / --do-not-cross-mountpoints
attic: /bin/bash: [Errno 95] Operation not supported: 'kanta.attic/index.tmp'
Traceback (most recent call last):
  File "/usr/bin/attic", line 3, in <module>
    main()
  File "/usr/lib/python3/dist-packages/attic/archiver.py", line 715, in main
    exit_code = archiver.run(sys.argv[1:])
  File "/usr/lib/python3/dist-packages/attic/archiver.py", line 705, in run
    return args.func(args)
  File "/usr/lib/python3/dist-packages/attic/archiver.py", line 128, in do_create
    self._process(archive, cache, args.excludes, args.exclude_caches, skip_inodes, path, restrict_dev)
  File "/usr/lib/python3/dist-packages/attic/archiver.py", line 177, in _process
    os.path.join(path, filename), restrict_dev)
  File "/usr/lib/python3/dist-packages/attic/archiver.py", line 177, in _process
    os.path.join(path, filename), restrict_dev)
  File "/usr/lib/python3/dist-packages/attic/archiver.py", line 163, in _process
    archive.process_file(path, st, cache)
  File "/usr/lib/python3/dist-packages/attic/archive.py", line 402, in process_file
    chunks.append(cache.add_chunk(self.key.id_hash(chunk), chunk, self.stats))
  File "/usr/lib/python3/dist-packages/attic/cache.py", line 180, in add_chunk
    self.repository.put(id, data, wait=False)
  File "/usr/lib/python3/dist-packages/attic/repository.py", line 360, in put
    self.segments.setdefault(segment, 0)
AttributeError: 'Repository' object has no attribute 'segments'

How to fix this?

shrx avatar Feb 26 '15 13:02 shrx

The issue seems to be with the filesystem - I want to create the backup on a HFS+ formatted disk.

shrx avatar Feb 26 '15 13:02 shrx

So, just to clarify, can you please give attic version, OS informations about where attic is running (OS X? Release?) / backing up to (locally mounted disk?).

Besides the traceback, there was already a error msg before the exception happened:

attic: /bin/bash: [Errno 95] Operation not supported: 'kanta.attic/index.tmp'

So, precisely what operations needed were not supported?

ThomasWaldmann avatar Mar 07 '15 23:03 ThomasWaldmann

Note: this could be related to issue #202, similar exception there.

ThomasWaldmann avatar Mar 09 '15 16:03 ThomasWaldmann

Sorry for late response. attic version: 0.13-1 OS: Xubuntu 14.10 backing up to: external disk connected via USB I don't know about the specific error, will have to check again.

shrx avatar Mar 09 '15 16:03 shrx

Maybe also try attic 0.14.

ThomasWaldmann avatar Mar 09 '15 17:03 ThomasWaldmann

The error is just with one folder with afuse-mounted remote directories not accessible to attic.

shrx avatar Mar 14 '15 11:03 shrx

Interesting. Can you clarify what you mean with "not accessible to attic"?

ThomasWaldmann avatar Mar 14 '15 12:03 ThomasWaldmann

This is the only error I get from attic:

attic: /home/shrx/net: [Errno 13] Permission denied: '/home/shrx/net'

The permissions are

drwx------  1 shrx shrx      0 1970/01/01 01:00:00 net

shrx avatar Mar 14 '15 13:03 shrx

@shrx so when you ran attic, you were using another user/group than shrx/shrx?

as a side note, the time stamp on that directory looks suspicious, like a 0 timestamp + 1h tz offset.

ThomasWaldmann avatar Mar 14 '15 18:03 ThomasWaldmann

Yes, I am running attic with sudo.

shrx avatar Mar 14 '15 18:03 shrx

sudo root? or sudo someoneelse?

ThomasWaldmann avatar Mar 14 '15 18:03 ThomasWaldmann

just sudo attic

shrx avatar Mar 14 '15 19:03 shrx

hmm, just a guessing: could the error when accessing the afuse-mounted stuff maybe be related to ACL / xattr support code (like trying to read ACLs/xattrs although they are not supported there)?

@shrx could you reproduce on unmodified and slightly modified code?

ThomasWaldmann avatar May 23 '15 16:05 ThomasWaldmann

I have a backup system which involves three hosts making backups to a same repository on a central server. I am hitting this bug fairly regularly. I added some debug prints and it seems the problem is in repository.prepare_txn: it immediately sets self._active_txn to True, then tries to obtain a lock. The lock fails with: OSError: [Errno 35] Resource deadlock avoided This is translated to WriteLockFailed exception; However, the caller seems to ignore the exception and calls put() instead. It thinks that transaction is already active (since _active_txn is true) and fails when trying to access segments().

theamk avatar Jul 11 '15 22:07 theamk

@theamk I fixed that already, see the 2nd commit in https://github.com/jborg/attic/pull/228

ThomasWaldmann avatar Jul 12 '15 00:07 ThomasWaldmann