desktop-packages team mailing list archive

[Bug Watch Updater <1511468@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 1 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=92746.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2015-10-30T19:32:23+00:00 Graeme Hewson wrote:

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.

That is, if the executable is fine as it is, and is designed to accept
only relative paths, then that should be stated in the man page, perhaps
with an example.

On the other hand, if it's decided that the executable should accept
absolute paths, then it would be helpful to accept relative paths too,
as now, and that too should be documented.

According to the man pages, I'm running udisks 2.1.5.

(Originally reported at
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1511468 because
the man pages mention the distribution bug tracker. :)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1511468/comments/2


** Changed in: udisks
       Status: Unknown => Confirmed

** Changed in: udisks
   Importance: Unknown => Medium

-- 
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 udisks:
  Confirmed
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/udisks/+bug/1511468/+subscriptions