I know I'm the one who suggested this, but I feel bad about it already. As a workaround, it might do for now.

We should also support network paths like \\server\share\path\to\file and long-filename paths like \\?\C:\long\path. There are also funny names starting with \Device\LanmanRedirector and \Device\MUP (note: only one backslash), and we even had a customer once who compiled files from such paths. To support all those, it should suffice to check if the absolute path starts with \.

I know I'm the one who suggested this, but I feel bad about it already.

Yes, as you said, it's a workaround - and I'm hoping we can get extractor support to replace this in the not too distant future. @ian-semmle please could we turn this into a planned task if we haven't done so already?

To support all those, it should suffice to check if the absolute path starts with \

If you're happy that there are no Unix absolute paths that don't begin without a \, I'll switch to this strategy.

It turns out that File.getAbsolutePath converts \ to / on Windows, so a network share will be //server/share/path. It's documented in its QLDoc.

I think it'll definitely be a Windows file system if the second character is : (like you have now) or /. An absolute Unix path that's been normalised will have had duplicate slashes merged. To make sure this rules definitely won't match files compiled on Linux, I've started this query: https://lgtm.com/query/4684586825962173629/. The results aren't complete at the time of writing, but hopefully they will be soon.

I've started this query:

I actually ran a similar query with just the case for : previously. It looks like yours has no results so it should be safe to add the / case.

(done)