After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 771384 - find_mount_entry_for_file: assertion failed: (entry != NULL)
find_mount_entry_for_file: assertion failed: (entry != NULL)
Status: RESOLVED DUPLICATE of bug 747540
Product: gvfs
Classification: Core
Component: trash backend
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Allison Karlitskaya (desrt)
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2016-09-13 17:58 UTC by Owen Taylor
Modified: 2016-09-14 07:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Owen Taylor 2016-09-13 17:58:52 UTC
On an ostree system, / is the same filesystem as /sysroot. The gunixmounts.c finds /sysroot first, then ignores / as a bind mount.

This means that when we try to find the filesystem for /home/<user>/.local/Trash

We look:

 /home/<user>/.local/Trash
 /home/<user>/.local
 /home/<user>
 /home
 /

and don't find a mount at any of these, there is an assertion failure in daemon/trashlib/trashwatcher.c:119:find_mount_entry_for_file().

http://build.gnome.org/continuous/buildmaster/builds/2016/09/13/53/smoketest-classic/work-gnome-continuous-x86_64-runtime/journal.txt

We actually, should have followed a symlink and looked at:

 /home/<user>/.local/Trash
 /home/<user>/.local
 /home/<user>
 /home => /var/home
 /var
 /

But it woudn't have fixed the issue. I'm not quite sure what the fix is:

 * Making the gunixmounts.c code consider / rather than /sysroot to be the "real root" would superficially fix it, but doesn't actually help, because the bind mounts don't have to have that structure - a filesystem could be mounted at /a and /b and not at /.
 * Not trying to detect and remote bind mounts in gunixmounts.c would fix this, but might confuse other code.

Could just not use gunixmounts.c t all here and directly parse /proc/mounts to look for nfs mounts, but that would hurt portability.
Comment 1 Ondrej Holy 2016-09-14 07:23:40 UTC
Thanks for your bug report. I think that the only right way is to convince g_unix_mounts_get to return the mounts we need, which I think is a duplicate of Bug 747540. I hope this will be fixed by the recently added libmount support (Bug 522053)...

*** This bug has been marked as a duplicate of bug 747540 ***