GNOME Bugzilla – Bug 552912
glib-2.18 /live-g-file/test_copy_move failed when run as root
Last modified: 2018-02-16 11:48:04 UTC
make check results : /live-g-file/test_copy_move: do_copy_move: 'dir1/subdir' --> 'dir-target' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir1/subdir' --> '.' res = 0, error code 2 = Target file exists do_copy_move: 'dir1/subdir' --> 'target-file' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir1/subdir' --> 'not_exists' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir1/subdir' --> 'dir_no-access' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir1/subdir' --> 'dir_no-write' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir2' --> 'dir-target' do_copy_move: 'dir-target' --> 'dir-target' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir-target' --> '.' res = 0, error code 2 = Target file exists do_copy_move: 'dir-target' --> 'target-file' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir-target' --> 'not_exists' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir-target' --> 'dir_no-access' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir-target' --> 'dir_no-write' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'target-file' --> 'dir-target' do_copy_move: 'target-file' --> '.' res = 0, error code 2 = Error opening file '/mnt/md0/sources/glib-2.18.1/gio/tests/testdir_live-g-file/target-file': File exists do_copy_move: 'target-file' --> 'target-file' res = 0, error code 4 = Error opening file '/mnt/md0/sources/glib-2.18.1/gio/tests/testdir_live-g-file/target-file/target-file': Not a directory do_copy_move: 'target-file' --> 'not_exists' res = 0, error code 1 = Error opening file '/mnt/md0/sources/glib-2.18.1/gio/tests/testdir_live-g-file/not_exists/target-file': No such file or directory do_copy_move: 'target-file' --> 'dir_no-access' ** ERROR:live-g-file.c:702:do_copy_move: assertion failed (res == FALSE): (1 == 0) FAIL System info: CPU E2160 @ 1.80GHz stepping 0d Linux 2.6.26.5 #1 SMP PREEMPT Tue Sep 9 11:07:57 CEST 2008 x86_64 GNU/Linux current glibc gcc version 4.3.3 20080911 ext2 on raid-1 (mirror) make check was run as root, LC_ALL=C Any idea what went wrong? Possibly on my side. -- Klaus
Same here with glib-2.18.1 Linux phoenix 2.6.26-gentoo-r1 #2 SMP PREEMPT Thu Sep 11 16:13:29 EEST 2008 x86_64 Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux
It seems this is a test for "source or target path permission denied" which might fail because root always has permission.. Running as a regular user seems to get past that, but fails with the following instead: TEST: live-g-file... (pid=22332) /live-g-file/prep_clean_structure: Cleaning target testing structure in 'testdir_live-g-file'... deleting 'dir1' deleting 'subdir' deleting 'dir-target' deleting 'dir2' deleting 'target-file' deleting 'dir_no-access' ** ERROR:live-g-file.c:1057:cleanup_dir_recurse: assertion failed: (error == NULL) FAIL
Whoops, posted too quickly - the other error happened because I had testdir_live-g-file still there from the failed run with root, so running at the user it just couldn't delete that due to root having had created it with no write permissions for the user. Having cleaned that up it passes gio/tests with a regular user
Same, here. Running gio/tests as non-root the tests passed ok. So the non-bug 552912 can be closed.
This is a bug that needs fixing or a workaround so that make check doesn't fail wrongly when ran as root. In Gentoo maintainers and users can run the tests as the normal upgrade or install process, and with a common package manager option that gets ran as root. There are at least two benefits for the tests working fine for this case: a) users can be more confident that their upgrade will work good as the tests passed (if they fail the upgrade process bails out), as we don't have to disable the tests run; b) gtk+ codebase gets a good testing on a big set of different architectures and system states, where the tests should pass everywhere (we forward all test failures - most of the time they are problems in the tests themselves, but not always) Currently I'm forced to carry a patch in the Gentoo glib-2.18.1 package that comments out the TEST_NO_ACCESS tests out of live-g-file until this bug is resolved in a better way.
Created attachment 154262 [details] [review] Expect the permission tests to succeed when running as root I want to make the test suite fatal in Debian, and I'll use this patch to fix these two tests. Subject: [PATCH] Don't fail a couple of tests when running as root root can access and write to a directory when it doesn't have exec and write permissions respectively. So expect the tests that check that to succeed rather than to fail when running as root. https://bugzilla.gnome.org/show_bug.cgi?id=552912
I don't think its right to always do this check. The target path for the checks in live-g-file is settable and may not always be a unix path. For instance, its also used for testing gvfs backends. It needs to check that the target is a local file before checking for root.
Created attachment 154425 [details] [review] Expect the permission tests to succeed when running as root, take 2 (In reply to comment #7) > I don't think its right to always do this check. The target path for the checks > in live-g-file is settable and may not always be a unix path. For instance, its > also used for testing gvfs backends. It needs to check that the target is a > local file before checking for root. I'd do that, but there doesn't seem to be a reliable way to check if a file is local or not (and that's what Ryan has told me on IRC too). So here's a patch that will assume it is if the test was (likely) run from the GLib's test suite. If you can suggest a more reliable way of doing this, I'd be happy to give it a go.
I meant local in the "has unix path" sense, but that patch looks good too.
pushed
*** Bug 609447 has been marked as a duplicate of this bug. ***