Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Metadata-only changes are not recognized #2249

Closed
fd0 opened this issue Apr 23, 2019 · 0 comments

Comments

@fd0
Copy link
Member

commented Apr 23, 2019

Output of restic version

restic 0.9.5 compiled with go1.12.4 on linux/amd64

How did you run restic exactly?

$ echo foo > test

$ restic backup test
[...]
processed 1 files, 4 B in 0:00
snapshot 8c72321c saved

$ restic ls -l latest
repository 1e2b35f0 opened successfully, password is correct
snapshot 8c72321c of [/home/fd0/shared/work/go/src/github.com/restic/restic/test] filtered by [] at 2019-04-23 20:39:59.152281409 +0200 CEST):
-rw-r--r--  1000   100      4 2019-04-23 20:39:55 /test

$ sudo chown root test

$ restic backup test
[...]
processed 1 files, 4 B in 0:00
snapshot 2a34805c saved

$ restic ls -l latest
repository 1e2b35f0 opened successfully, password is correct
snapshot 2a34805c of [/home/fd0/shared/work/go/src/github.com/restic/restic/test] filtered by [] at 2019-04-23 20:40:12.099541936 +0200 CEST):
-rw-r--r--  1000   100      4 2019-04-23 20:39:55 /test

$ ls -al test
-rw-r--r-- 1 root users 4 Apr 23 20:39 test

What backend/server/service did you use to store the repository?

This affects all backends.

Expected behavior

restic should pick up that the ownership of the file has changed, and record that in the repo

Actual behavior

restic does not recognize that the owner has changed.

Steps to reproduce the behavior

See above

Do you have any idea what may have caused this?

It's a bug: the new archiver code introduced with 0.9.0 calls fileChanged() here to decide whether or not to re-read the file. It mostly checks mtime, the inode for the file and the size and type.

If fileChanged() returns false, the old node is copied over, which not only (correctly) copies over the list of blobs the file consists of, but also all metadata information. The current ownership and other attributes which can be changed without changing the mtime are discarded.

I've verified that the old archiver code in 0.8.3 does not have this bug.

Thank you very much @aldem for being persistent and making us aware of this issue!

Do you have an idea how to solve the issue?

Do it properly: if the file hasn't changed, only copy over the list of blobs, but read the metadata anew.

@fd0 fd0 added the bug label Apr 23, 2019

@fd0 fd0 self-assigned this Apr 23, 2019

fd0 added a commit that referenced this issue Apr 24, 2019

fd0 added a commit that referenced this issue Apr 24, 2019

@fd0 fd0 referenced this issue Apr 24, 2019
6 of 7 tasks complete

@fd0 fd0 closed this in #2252 Apr 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.