XAttribute compare failed about snapper

[aschnell]

Fix looks good to me. Ondrej?

At the same time I wonder why snapper wants to compare xattrs for /dev/core as /dev is normally on tmpfs these days. What is the output of df on the system?

[oniko]

Is it really problem in cmpFilesXattrs()? I'm trying to figure out why the snapper tries to compare non-existing links in first place...

[aschnell]

The /dev directory in the snapshots can have entries (completely different to the real /dev). While mounting the tmpfs at /dev the original content is simply buried. I have a system here where this is the case.

On the system here I get the same error for /dev/lp0. Will debug further.

[oniko]

EDIT: I was wrong, still investigating:)

[mknjc]

Its a Gentoo System with systemd and automounted devtmpfs.

Ragnarok-Micro ~ # df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda2       229G     11G  217G    5% /
devtmpfs        983M       0  983M    0% /dev
...
Ragnarok-Micro ~ # mount
/dev/sda2 on / type btrfs (rw,noatime,space_cache)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1006484k,nr_inodes=251621,mode=755)
...
Ragnarok-Micro ~ # 

Gentoo "installation images" contains a pre generated dev folder:

Ragnarok-Micro ~ # mount --bind / /mnt/gentoo/
Ragnarok-Micro ~ # ls /mnt/gentoo/dev/
console  hda1   hda14  hda19  hda23  hda28  hda32  hda8   port    sda10  sda15  sda6  sdb1   sdb14  sdb5  sdc    sdc13  sdc4  sdc9   sdd12  sdd3  sdd8    tty    tty12  tty17  tty21  tty26  tty30  tty35  tty4   tty44  tty49  tty53  tty58  tty62  urandom
core     hda10  hda15  hda2   hda24  hda29  hda4   hda9   ptmx    sda11  sda2   sda7  sdb10  sdb15  sdb6  sdc1   sdc14  sdc5  sdd    sdd13  sdd4  sdd9    tty0   tty13  tty18  tty22  tty27  tty31  tty36  tty40  tty45  tty5   tty54  tty59  tty63  zero
fd       hda11  hda16  hda20  hda25  hda3   hda5   input  random  sda12  sda3   sda8  sdb11  sdb2   sdb7  sdc10  sdc15  sdc6  sdd1   sdd14  sdd5  stderr  tty1   tty14  tty19  tty23  tty28  tty32  tty37  tty41  tty46  tty50  tty55  tty6   tty7
full     hda12  hda17  hda21  hda26  hda30  hda6   mem    sda     sda13  sda4   sda9  sdb12  sdb3   sdb8  sdc11  sdc2   sdc7  sdd10  sdd15  sdd6  stdin   tty10  tty15  tty2   tty24  tty29  tty33  tty38  tty42  tty47  tty51  tty56  tty60  tty8
hda      hda13  hda18  hda22  hda27  hda31  hda7   null   sda1    sda14  sda5   sdb   sdb13  sdb4   sdb9  sdc12  sdc3   sdc8  sdd11  sdd2   sdd7  stdout  tty11  tty16  tty20  tty25  tty3   tty34  tty39  tty43  tty48  tty52  tty57  tty61  tty9
Ragnarok-Micro ~ # 

so the easiest way to fix the bug for me would be deleting all pregenerated dev nodes. But I think it should be fixed in snapper itself.

Snapper tries to read the xattribs with fgetxattr (FileUtils.cc:451 SDir::getxattr) but the openat fails with ENXIO.

7635  newfstatat(9, "core", {st_mode=S_IFCHR|0600, st_rdev=makedev(1, 6), ...}, AT_SYMLINK_NOFOLLOW) = 0
7635  newfstatat(6, "core", {st_mode=S_IFCHR|0600, st_rdev=makedev(1, 6), ...}, AT_SYMLINK_NOFOLLOW) = 0
7635  openat(9, "core", O_RDONLY|O_NOFOLLOW|O_NOATIME|O_CLOEXEC) = -1 ENXIO (No such device or address)
7635  open("/var/log/snapper.log", O_WRONLY|O_CREAT|O_APPEND|O_CLOEXEC, 0666) = 10
7635  fstat(10, {st_mode=S_IFREG|0640, st_size=4207409, ...}) = 0
7635  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x293932ea000
7635  fstat(10, {st_mode=S_IFREG|0640, st_size=4207409, ...}) = 0
7635  lseek(10, 4207409, SEEK_SET)      = 4207409
7635  write(10, "2013-05-29 18:07:38 ERR libsnapp"..., 192) = 192
7635  close(10)                         = 0
7635  munmap(0x293932ea000, 4096)       = 0
7635  futex(0x293924c8044, FUTEX_WAKE_PRIVATE, 2147483647) = 0
7635  open("/var/log/snapper.log", O_WRONLY|O_CREAT|O_APPEND|O_CLOEXEC, 0666) = 10

Why not use getxattr or llistxattr?

[oniko]

Thanks for the report. I thought the problem was in SDir.listxattr, but it was one step later. So I was not so wrong as I thought in the first place:)

To sum it up: open(at) syscall ends with ENXIO/ENODEV for non-existant devices (dev node is present in fs, but the real device is not in kernel) we need to deal with them the same way as we deal with symbolic links. Arvin, do you want me to submit the patch? (I'll add a regression test for this case as well)

[aschnell]

Fixed with commit 250de17. If the open fails with ENXIO (and also EWOULDBLOCK) the same fallback as for symbolic links is used.