Comment 3 for bug 1511468

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. :)