RetroArch freezes when intent is sent with a remote saf mount path

[Terramoto]

I've just recently started to play with emulators and installed RetroArch + Daishijo on Android, because i already had a Batocera instance, in the living room hosting roms, i didn't want to copy the files and decided to setup a remote mount using rclone, through an app called "RSAF" which essentially uses rclone to mount the remote folder locally.
i'm able to load the rom directly from RetroArch but if sent via intent using -e ROM {file.uri} it causes it to freeze.

Issue

When starting games on RetroArch from Daishijiro using {file.path} fails with file not exist in path. Switching to {file.uri} causes RetroArch to freeze after obtaining the file descriptor.

Reproduce

In Daishijiro add the path and scan for roms, in settings edit player arguments to replace {file.path} with {file.uri}

example intent:

-n com.retroarch/com.retroarch.browser.retroactivity.RetroActivityFuture
-e ROM content://io.github.x0b.rcx.vcp/tree/rclone%2Fremotes%2Fminipc%3A%2Froms%2Fgba/document/rclone%2Fremotes%2Fminipc%3A%2Froms%2Fgba%2FBanjo-Kazooie%20-%20Grunty's%20Revenge.gba 
-e LIBRETRO mgba
-e CONFIGFILE /storage/emulated/0/Android/data/com.retroarch/files/retroarch.cfg

It should load the game but instead it starts RetroArch with a blank screen and eventually timesout.

AI suggests it could to be related to how the stream size is retrieved, the following patch resolved the issue for me. I was wondering if someone could review the code to see if it's something that should be adapted or if it's not recommended.

retroarch-android-rsaf-content-uri.patch

[i30817]

@white-axe seems like something you'd want to see.

I myself dont get why there is a race condition that locks up things here so I'd guess you'd want to see the patch so you could tell the rationale and if its a api, or use of api bug instead

I'm personally suspicious of

+#if defined(ANDROID) && defined(HAVE_SAF)
+         if (stream->scheme == VFS_SCHEME_SAF && saf_size_cached)
+            stream->mapsize = (uint64_t)stream->size;
+         else
+#endif
          stream->mapsize = retro_vfs_file_seek_internal(stream, 0, SEEK_END);

One would think that using the vfs api to find the size would find the size instead of locking up, and a out of api alternative api would have been used if it works instead.

Maybe seek end is literally trying to transmit bytes instead of moving the cursor... Nah that would be dumb

Anyway if retroarch ever decides to accept directories as "content files" I suspect that would break this too, since directories are being filtered out purposefuly for some reason, probably the AI deciding that some dirs apis the size may be nonsense or used for something else.

[white-axe]

Does it work without the patch if you use com.retroarch/com.retroarch.browser.debug.CoreSideloadActivity instead of com.retroarch/com.retroarch.browser.retroactivity.RetroActivityFuture?