The short answers are:
- The ?? signify that the remaining pathname is unknown,
- you can't extract the absolute path and
- this is a feature, not a bug, of DTrace on OS X.
An explanation of these points requires some familiarity with DTrace; if appropriate then start with the introduction to the Solaris version.
iosnoop
is a script that exploits the DTrace observability
framework. In particular, it uses the io
provider's start
and done
probes; the start probe exposes a request's bufinfo_t
,
the target device's devinfo_t
and the corresponding file's
fileinfo_t
. The fileinfo_t
is not a native Darwin type:
it is a structure provided by dtrace(1) that provides a
convenient abstraction of a file for the benefit of users.
For example, amongst its members is fi_pathname
, which
should give the full pathname of a file.
Having an abstracted description shields users, and their scripts, from knowledge of and changes to the underlying implementation of the operating system. In theory, it also allows for a single script to run on different operating systems altogether.
A fileinfo_t is constructed and populated dynamically
using a DTrace translator described in /usr/lib/dtrace/io.d
.
This shows the transformation from the OS-specific types
to the abstraction. In the case of Snow Leopard I see that
fi_pathname
is constructed from the string "??/" followed by
some derivates of the IO buffer. I'm no Darwin expert but
I infer that it simply doesn't record full pathnames in its
vnodes. This, hence, is the origin of the "??" in the output
of your script and also the reason why I assume that the absolute
pathnames are unavailable.
Finally, your DTrace errors. For whatever reasons, Apple's port of DTrace is subtly crippled in that it precludes tracing of various processes, and the error message that you see is a characteristic symptom. Specifically, the complaint is about the line
start_uid[this->dev, this->blk] = (int)uid;
and it turns out that (again, on Snow Leopard), trying to evaluate
uid
on any of the launchd
, diskimages-help
and kernel_task
processes results in exactly this error. I presume that these
processes are "out of bounds" and the errors that you see are
the consequences of Apple's modifications.