It was Red Hat specific when it was introduced in 2004, was never
supported by mount(8) upstream, and was removed entirely in 2008.
It’s confusing for GLib to keep references to it around.
Thanks to Karel Zak for digging up the history of it:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2298#note_1294519
And thanks to Xidorn Quan for looking into it in the first place (see
!2298).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
There is already g_unix_mount_at function which allows to find certain
unix mount for given mount path. It would be useful to have similar
function for mount points, which will allow to replace custom codes in
gvfs. Let's add g_unix_mount_point_at.
There are glocalfile.h and glocalfileprivate.h header files currently.
None of those header files is public, so it doesn't make sense to have
two private headers for glocalfile.c. Let's remove glocalfileprivate.h.
This was mostly machine generated with the following command:
```
codespell \
--builtin clear,rare,usage \
--skip './po/*' --skip './.git/*' --skip './NEWS*' \
--write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).
Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.
There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.
If I’ve missed anything, please file an issue!
Signed-off-by: Philip Withnall <withnall@endlessm.com>
mtab_file_changed_id is not currently removed when finalizing, which
could potentially lead to segfaults. Let's remove the source when
finalizing to avoid this.
mtab_file_changed_id might be set on thread default context, but it is
always cleared on the global context because of usage of g_idle_add. This
can cause the emission of redundant "mounts-change" signals. This should
not cause any issues to the client application, but let's attach the idle
source to the thread-default context instead to avoid those races for sure.
The `get_mounts_timestamp()` function uses `mount_poller_time` when
`proc_mounts_watch_source` is set, but the `mount_poller_time` is not
initialized in the same time as `proc_mounts_watch_source`. This may
cause that zero, or some outdated value is returned. Let's initialize
`mount_poller_time` to prevent invalid values to be returned.
The Nautilus test suite often crashes with "GLib-FATAL-CRITICAL:
g_source_is_destroyed: assertion 'g_atomic_int_get (&source->ref_count)
> 0' failed" if it is started with "GIO_USE_VOLUME_MONITOR=unix". This
is because GUnixMountMonitor is simultaneously used from multiple
threads over GLocalFile and GVolumeMonitor APIs. Let's add guards for
proc_mounts_watch_source and mount_poller_time variables to prevent
those crashes.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/2030
Fixes build failure:
../gio/gunixmounts.c: In function ‘_g_get_unix_mounts’:
../gio/gunixmounts.c:742:53: error: ‘struct mnttab’ has no member named ‘mnt_opts’; did you mean ‘mnt_mntopts’?
742 | mntent.mnt_opts,
| ^~~~~~~~
| mnt_mntopts
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
If c_marshaller is provided during g_signal_new() registration, the
automatic va_marshaller will not be set. If we leave the c_marshaller as
NULL in the simple cases, both a c_marshaller and va_marshaller will be
set for us.
This is particularly helpful when dealing with stack traces from Linux
perf, which often cannot unwind the stack beyond the ffi_call_unix64
stack-frame on x86_64.
Related to GNOME/Initiatives#10
More mounts can have same mount path, but only the last one is
accessible. Thus we should always return the last matching mount from
g_unix_mount_at() and g_unix_mount_for(). This should also solve
problems with g_file_trash() on automounted filesystems, which are
caused by the recently added mount checks.
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1727
mntent-based implementation filter out mounts with device path that was
repeated. Consequently, it is not possible to show such mounts in UI even
with x-gvfs-show, because they are not returned from g_unix_mounts_get.
libmount-based implementation currently doesn't filter out any mounts
which causes issues to our volume monitors. Let's rather mark mounts
which don't point into fs root as system_internal. This approach won't be
affected by mount order as is mntent-based implementation. It will mark
more mounts as system_internal than it is filtered out with mntend-based
implementation, but there will be always possibility to show them in UI
over x-gvfs-show, which was not possible with mntend-based. We can
probably introduce some improvements later to not mark unique mounts as
system internal even if they don't point into fs root...
https://gitlab.gnome.org/GNOME/glib/issues/1271
Currently, there isn't API to determine root path for mounts created
over bind operation (or btrfs subvolumes). This causes issues to our
volume monitors if there is multiple mounts for one device, which can
happen with libmount-based implementation currently. Let's propagate
root path from libmount over g_unix_mount_get_root_path, so we can
handle this somehow in our volume monitors.
https://gitlab.gnome.org/GNOME/glib/issues/1271
They’re network file systems, but not system file systems (in the sense
that procfs is a system file system). This fixes them disappearing from
the sidebar in the UI.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1424
GVfsUDisks2VolumeMonitor handles x-gvfs-hide/x-gvfs-show mount options
used to overwrite our heuristics whether the mount should be shown, or
hidden. Unfortunately, it works currently only for mounts with
corresponding fstab entries, because the options are read over
g_unix_mount_point_get_options. Let's introduce g_unix_mount_get_options
to allow reading of the options for all sort of mounts (e.g. created
over pam_mount, or manually mounted).
(Minor fixes to the documentation by Philip Withnall
<withnall@endlessm.com>.)
https://bugzilla.gnome.org/show_bug.cgi?id=668132
All those logging functions already add a newline to any message they
print, so there’s no need to add a trailing newline in the message
passed to them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
Normally, the list of mounts is filtered to exclude mounts in
/run/media/$username where $username is not the current user. However,
root can access all the mounts under /run/media/, regardless of the
username — so there’s no point in filtering out those mounts.
In some cases, filtering them out is harmful. In the case of a system
service which uses GVolumeMonitor, for example, filtering them out means
the service cannot see automounted USB sticks belonging to user
sessions.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793994
Building against libmount installed into a non-default prefix wasn’t
working, as we were using #include <libmount/libmount.h> rather than
the correct #include <libmount.h> — all the mount.pc pkg-config files
set `Cflags: -I${includedir}/libmount`.
Fixing this while retaining the fallback support for versions of
libmount without a pkg-config file would have been tricky (we would need
to work out a suitable -I flag to set in LIBMOUNT_CFLAGS) to still be
able to use the correct #include path). Thankfully, libmount gained
pkg-config support a long time ago, so I think we can safely drop the
fallback code. In particular, Debian Jessie, Ubuntu Trusty, and CentOS 5
all ship a mount.pc file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793288
Skip accumulated events from file monitor which we are not able to handle
in a real time instead of emitting mounts_changed signal several times.
This should behave equally to GIOChannel based monitoring. See Bug 792235.
https://bugzilla.gnome.org/show_bug.cgi?id=793006
This will fix a few broken links in the documentation, and shut up a
load of gtk-doc warnings (but certainly not all of them).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790015
This is needed by gnome-control-center and gnome-settings-daemon; it
makes existing checks from gunixmounts.c public.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788927
"len" is only used by some platforms' implementations (as controlled
by various autoconf/#ifdef tokens) and only in a small codeblock in
those cases, but was declared based on a looser #ifdef heuristic and
in a larger scope. The result is an unused-variable warning when built
on some platforms. Move declaration to the local codeblocks that use
the variable, which also restricts it to the narrower set of platforms
where those codeblocks are used.
https://bugzilla.gnome.org/show_bug.cgi?id=689323
Commit 53ed180 improved mtab processing, however, also introduced bug
in code obtaining mount points. mtab was used by mistake also for
g_unix_mount_points_get implementation, which is obviously wrong and
fstab has to be used instead...
https://bugzilla.gnome.org/show_bug.cgi?id=781867
Fix get_mounts_timestamp() to not use a stat'ed mtime for /proc/ files.
Instead, use mount_poller_time if /proc/ watch is running, or otherwise
return a new generated timestamp to always assume mounts-changed, which
is safer than previous behaviour of always assuming mounts-not-changed
(as mtime never changes for /proc/ files when queried from the same
process).
We say it's safer because allows caches depending on:
g_unix_mounts_get(&time_read)
g_unix_mounts_changed_since()
to drop possibly outdated/duplicated values, as that was the case for the
GIO mounts cache used in gio/glocalfile.c which provides mount info for
g_file_query_filesystem_info() call, as described in below referenced bug.
This fix complements related commit bd9e266e11https://bugzilla.gnome.org/show_bug.cgi?id=787731
The /etc/mtab file is still used by some distributions (e.g. Slackware),
so it has to be monitored instead of /proc/self/mountinfo in order to
avoid races between g_unix_mounts_get and "mounts-changed" signal. The
util-linux is built with --enable-libmount-support-mtab in that case and
mnt_has_regular_mtab is used for checks. Let's use mnt_has_regular_mtab
also to determine which file to monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=779607
mnt_table_is_fs_mounted causes unwanted automount requests due to
canonicalization of source and target. It might be replaced by
mnt_table_find_source as per the documentation in order to prevent
the automounts, but it is redundant. All mtab entries should be already
mounted and thus mnt_table_is_fs_mounted result is always true (it
basically checks that the fs from mtab is in mtab). Let's remove
the check at all.
https://bugzilla.gnome.org/show_bug.cgi?id=781867
libmnt_context is useless. It contains cache which is useful for searching,
but it isn't used in our case. Let's use mnt_context_parse_mtab instead
directly and the mtab processing will be faster.
https://bugzilla.gnome.org/show_bug.cgi?id=781867
It's unnecessary, and only adds visual noise; we have been fairly
inconsistent in the past, but the semi-colon-less version clearly
dominates in the code base.
https://bugzilla.gnome.org/show_bug.cgi?id=669355
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
GLib has g_unix_mount_at (mount_path) already, let's add g_unix_mount_for
(file_path) for whatever path. GLib already contains some private code
for such task. Let's make this code public. This functionality is needed
by GVfs (see Bug 771431) in order to avoid copy-and-pasting.
https://bugzilla.gnome.org/show_bug.cgi?id=772160
/proc/self/mountinfo is used to monitor changes of mounts with libmount.
However, GFileMonitor is used currently to monitor this file, which
doesn't work and consequently "changed" signal is never emitted. Special
monitoring needs to be used instead, same as it is used for /proc/mounts.
https://bugzilla.gnome.org/show_bug.cgi?id=662946
Use mnt_context_get_mtab instead of using mnt_context_get_table(), since
that's the recommended way of accessing mtab/mountinfo information, and
also because that way the (struct libmnt_table *) will get automatically
deallocated when calling mnt_free_context()
https://bugzilla.gnome.org/show_bug.cgi?id=769238
