Files
RedBear-OS/local/recipes/libs/glib/source/docs/reference/gio/migrating-gnome-vfs.md
T
vasilito cee25393d8 fix: boot process improvements — dependency cycle, INIT_NOTIFY, probing loop, and log spam fixes
- Fix P15-8-init-cycle-detection.patch: replace visiting+error with seen+silent-skip
  to eliminate 11 false-positive 'dependency cycle detected' errors on shared deps
- Fix P0-daemon-fix-init-notify-unwrap.patch: remove eprintln! for missing
  INIT_NOTIFY (expected for oneshot_async services, ~7 daemons affected)
- Fix driver-manager hotplug loop: add PERMANENTLY_SKIPPED static set shared
  between hotplug handler and DriverConfig::probe() to stop infinite re-probing
  of Fatal/NotSupported/deferred-exhausted device+driver pairs (e.g. ided)
- Fix driver-manager log_timeline: suppress repeated EPIPE/ENOENT errors with
  AtomicI32 dedup and AtomicBool one-shot guards for boot timeline JSON
- Add driver-manager SIGTERM handler, ACPI bus registration, --status mode,
  driver reap loop, graceful shutdown, and reduced deferred retries (30→3)
2026-05-17 12:34:02 +03:00

4.1 KiB

Title: Migrating from GnomeVFS to GIO SPDX-License-Identifier: LGPL-2.1-or-later SPDX-FileCopyrightText: 2010 Matthias Clasen

Migrating from GnomeVFS to GIO

Comparison of GnomeVFS and GIO concepts

GnomeVFS GIO
GnomeVFSURI [iface@Gio.File]
GnomeVFSFileInfo [class@Gio.FileInfo]
GnomeVFSResult [struct@GLib.Error], with G_IO_ERROR values
GnomeVFSHandle & GnomeVFSAsyncHandle [class@Gio.InputStream] or [class@Gio.OutputStream]
GnomeVFSDirectoryHandle [class@Gio.FileEnumerator]
MIME type content type
GnomeVFSMonitor [class@Gio.FileMonitor]
GnomeVFSVolumeMonitor [class@Gio.VolumeMonitor]
GnomeVFSVolume [iface@Gio.Mount]
GnomeVFSDrive [iface@Gio.Volume]
- [iface@Gio.Drive]
GnomeVFSContext [class@Gio.Cancellable]
gnome_vfs_async_cancel() [method@Gio.Cancellable.cancel]

Trash handling

The handling of trashed files has been changed in GIO, compared to gnome-vfs. gnome-vfs has a home-grown trash implementation that predates the freedesktop.org Desktop Trash Can specification that is implemented in GIO. The location for storing trashed files has changed from $HOME/.Trash to $HOME/.local/share/Trash (or more correctly $XDG_DATA_HOME/Trash), which means that there is a need for migrating files that have been trashed by gnome-vfs to the new location.

In gnome-vfs, the trash:// scheme offering a merged view of all trash directories was implemented in Nautilus, and trash-handling applications had to find and monitor all trash directories themselves. With GIO, the trash:// implementation has been moved to gvfs and applications can simply monitor that location:

static void
file_changed (GFileMonitor      *file_monitor,
              GFile             *child,
              GFile             *other_file,
              GFileMonitorEvent  event_type,
              gpointer           user_data)
{
  switch (event_type)
  {
  case G_FILE_MONITOR_EVENT_DELETED:
    g_print ("'%s' removed from trash\n", g_file_get_basename (child));
    break;
  case G_FILE_MONITOR_EVENT_CREATED:
    g_print ("'%s' added to trash\n", g_file_get_basename (child));
    break;
  default: ;
  }
}

static void
start_monitoring_trash (void)
{
  GFile *file;
  GFileMonitor *monitor;

  file = g_file_new_for_uri ("trash://");
  monitor = g_file_monitor_directory (file, 0, NULL, NULL);
  g_object_unref (file);

  g_signal_connect (monitor, "changed", G_CALLBACK (file_changed), NULL);

  /* ... */

}

GIO exposes some useful metadata about trashed files. There are trash::orig-path and trash::deletion-date attributes. The standard::icon attribute of the trash:// itself provides a suitable icon for displaying the trash can on the desktop. If you are using this icon, make sure to monitor this attribute for changes, since the icon may be updated to reflect that state of the trash can.

Moving a file to the trash is much simpler with GIO. Instead of using gnome_vfs_find_directory() with GNOME_VFS_DIRECTORY_KIND_TRASH to find out where to move the trashed file, just use the [method@Gio.File.trash] method.

Operations on multiple files

gnome-vfs has the dreaded gnome_vfs_xfer_uri_list() function which has tons of options and offers the equivalent of cp, mv, ln, mkdir and rm at the same time.

GIO offers a much simpler asynchronous task functionality instead, that lets you schedule a function to be called in a separate thread, making sure that updates are scheduled within the main context that created the task, so you can update your user interface. See: [class@Gio.Task].

Mime monitoring

gnome-vfs offered a way to monitor the association between mime types and default handlers for changes, with the GnomeVFSMIMEMonitor object. GIO does not offer a replacement for this functionality at this time, since we have not found a compelling use case where GnomeVFSMIMEMonitor was used. If you think you have such a use case, please open an issue on the GLib issue tracker.