desktop-packages team mailing list archive

[Sebastien Bacher <seb128@xxxxxxxxxx>]

Thanks, that should probably be reported upstream on
https://bugs.freedesktop.org/enter_bug.cgi?product=udisks

** Changed in: udisks2 (Ubuntu)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to udisks2 in Ubuntu.
https://bugs.launchpad.net/bugs/1511468

Title:
  udisksctl doesn't accept absolute object-paths

Status in udisks2 package in Ubuntu:
  New

Bug description:
  If I issue "udisksctl dump" and then issue "udisksctl info" for one of
  the objects in the dump, I get an error message. For instance:

  $ udisksctl info --object-path
  /org/freedesktop/UDisks2/drives/TSSTcorp_CDDVDW_SH_S223Q_TSSTcorp_CDDVDW_SH_S223Q

  (udisksctl info:4995): GLib-GIO-CRITICAL **: g_dbus_object_manager_get_object: assertion 'g_variant_is_object_path (object_path)' failed
  Error looking up object with path /org/freedesktop/UDisks2/drives/TSSTcorp_CDDVDW_SH_S223Q_TSSTcorp_CDDVDW_SH_S223Q

  This is confusing.

  It turns out that object paths must be relative to
  /org/freedesktop/UDisks2. For instance:

  $ udisksctl info --object-path drives/TSSTcorp_CDDVDW_SH_S223Q_TSSTcorp_CDDVDW_SH_S223Q
  /org/freedesktop/UDisks2/drives/TSSTcorp_CDDVDW_SH_S223Q_TSSTcorp_CDDVDW_SH_S223Q:
    org.freedesktop.UDisks2.Drive:
  [snip]

  I don't know if this is a bug in the executable or in the man page. In
  either case, I suggest it would be very helpful to state in
  udisksctl(1) that relative object paths must/can (whichever it is) be
  used.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1511468/+subscriptions