Compilation of v11 on Ubuntu 16.04 - ends in Error 2 on check

[George Jone]

make check

Results in:
[snipped]

Everything OK
rm -r bench/disk1/a
rm -r bench/disk3/a
./snapraid --test-skip-device --test-skip-self --test-force-progress --no-warnings --test-parity-limit=3333333 --test-force-order-alpha -q -q -q -c ./test/test-par6-hole.conf fix -l test.log
Error creating empty file 'bench/disk1/a/palx7s1.zkkxzb+'. Operation not permitted.
WARNING! Without a working data disk, it isn't possible to fix errors on it.
Stopping

    4718 errors
    4717 recovered errors
       1 UNRECOVERABLE errors
DANGER! There are unrecoverable errors!
Makefile:1123: recipe for target 'check-local' failed
make[1]: *** [check-local] Error 1
make[1]: Leaving directory '/root/git/snapraid-11.0'
Makefile:968: recipe for target 'check-am' failed
make: *** [check-am] Error 2

[John]

https://github.com/amadvance/snapraid/releases/download/v11.0/snapraid-11.0.tar.gz works fine (make check) on my Ubuntu 16.04.1 LTS x64.

[George Jone]

Tried again. Same result.
Terminal capture: https://asciinema.org/a/87zc043mer7ucuiggmcync6gr

[Jessie Taylor]

How full is the filesystem you are building / checking on?

What filesystem is it?

[John]

There's something with the file here:

Error opening file 'bench/disk1/a/.xpfblg2'. Operation not permitted.

Disk full (also check df -i), some permission issue (yes, I see you're root but who knows), chattr, etc.

[George Jone]

Appreicate it John.

It's an ext4 with 100G+ available (SSD).
It is definitely curious. I'll try buidling in a VM and see what I get.
The build as you noticed is attempted as root and in root's home dir.

My production install uses the PPA so I'm waiting on that to be published, but figured I'd give the compile a go. Will revert on the VM build.

[George Jone]

Fired up a Xenial VM on Debian.
Compiled and make check without error both as user and root.

I do have Sophos AV on the original box which may be inhibiting a unit-test / check. Unfortunately too much heavy lifting involved to debug. Seems it's a "my problem not yours". Glad to discover that.

Good luck all.

[Andrea Mazzoleni]

Hi,

Just checked the related source code. There is no explicable reason for this error. It's an open() call that returns the EPERM error, that it's not even theorically possible from the manpage.

Note that for a permission problem the expected error is instead EACCESS -> "Permission denied".

I suppose it's just an interference of the antivirus. The SnapRAID unit test is something that can trigger latent bugs with such tools that mess with the filesystem.

Ciao,
Andrea

[George Jone]

I needed to know - these are the things that gnaw at me at 3am ... so I did the work.
Good news is confirmation, it was the AV.

Thanks for such a great solution.