MTP fundamentally doesn't support this capability. No matter how you try and dress it up, you must copy the file locally to open it. Some tools like mtpfs or go-mtpfs will do an implicit copy to a temp file and then open that, but I consider this far too heavy weight to try and hide away from the user. The latency associated with large files is huge (could take minutes to copy) and you can't pretend a multi-gigabyte movie file is something you can casually throw in /tmp.

The only correct way to handle it is for the application trying to open the file to be aware of this constraint. evince is the gold standard here. It knows it has to make a local copy, so it copies it, while showing a progress bar inside its own windows, and making sure the temp file is deleted when you quit. This kind of functionality can only be provided by the application - any other piece in the chain (MTP backend, gvfsd, nautilus) can only provide an imperfect kludge.

Why can't you support this? I understand you can't support read+write or seeks, but a simple "stream the data in the file" operation should be possible, should it not?

There's a couple of problems on the mtp side:

1) Once you start downloading, you probably cannot cancel. In my testing, canceling a download will confuse the device so completely that you have to unplug and replug it to recover. I'm sure some devices can recover, but the google reference mtp stack cannot.

2) MTP fundamentally only supports one operation at a time. So once you start streaming, you cannot do anything else until it finishes, and because of 1) you can't cut it short. You'd have to stream it to /dev/null, effectively, if the user closes the stream.

Of course, this is true for normal downloads as well,  but there you have a progress meter telling you that it's busy and for how much longer.

The windows 7 code doesn't offer streaming either. It does copy-to-temp in the file manager.