The OVAL Interpreter is generating an "unknown error" message when collecting Windows paths that use all forward slashes for path separators. We are probably not handling an error or exception properly some where. The attached file contains an example object that generates this error message.
The exception comes from FileProbe:155, because it
assumes that Common::SplitFilePath() will always
return a non-NULL value. In this case, it does,
so the exception is thrown. NULL is returned
because SplitFilePath splits on Common::fileSeparator,
which is '\', but the path uses '/', so no split
point is found.
That part of the FileProbe code handles partial
matches when the file wasn't found, but on my system,
the file does exist. So that suggests another bug.
This second bug stems from AbsFileFinder::FilePathExists(),
where it again uses Common::SplitFilePath() to split
the filepath on the same separator char as above.
Again, NULL is returned, but here it is checked for,
so rather than a crash/exception, you get a false
return value (erroneously indicating the file does
not exist.)
Filepaths tend to be handled in ovaldi by splitting them
into path+filename pairs, and then treating them as if
<path>+<filename> entities were used. This splitting
is inflexible and doesn't work if any separator char
other than '\' (on windows) is used, so the code falls
down.