Skip to content

gdocumentportal: Handle EROFS and similar errors more gracefully

Simon McVittie requested to merge wip/smcv/documents-portal-erofs into main

  • gdocumentportal: Factor out opening_ro_might_succeed()

    No functional change.

  • gdocumentportal: Treat more error codes as a permissions error

    If the file to be added is on a read-only filesystem, opening read/write will fail with EROFS. In this case we should fall back to opening it read-only, the same way we already do if write access is forbidden by DAC or MAC.

    An easy way to reproduce this test failure is to build and test GLib in a podman container, with its source code read-only and its build directory read/write:

      podman run --rm -it \
  -v $(pwd):$(pwd):ro \
  -v $(pwd)/_build:$(pwd)/_build:rw \
  -w $(pwd) ...

    Before this commit, the dbus-appinfo test would fail, because opening ${srcdir}/gio/tests/org.gtk.test.dbusappinfo.flatpak.desktop read/write would fail with EROFS.

    For completeness, give similar handling to the other error codes documented in Linux open(2) that might succeed if re-attempted using read-only access: according to that documentation, we could get EPERM if opening read/write is prevented by fcntl F_ADD_SEALS, or ETXTBSY if the file is an executable that is currently being run.

Merge request reports