Videolan vlc.exe tries to write uneeded copy of "files.mp4" inside the box

[Rngexile]

I've just noticed the same thing as someone in
https://www.wilderssecurity.com/threads/released-sandboxie-plus-sbie-fork-versions-with-signed-driver.434924/page-34

1/ When launched outside sandboxie, the media player vlc.exe (v3.12 https://www.videolan.org/) can read video files (examples) AAA.mp4 and a renamed copy AAA.mp4.mkv (or avi or maybe other containers) without the need to (re)write these files.

I can see in procmonitor (from Sysinternals) that vlc.exe only needs "Desired Access: Generic Read" on the file AAA.mp4.mkv
and needs at some points "Desired Access: Generic Read/Write, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, AllocationSize: n/a, OpenResult: Opened" for the file AAA.mp4.

Still, no (re)writes of AAA.mp4, no change on the file. Expected behaviour.

2/ But, when vlc is launched inside his box, it seems sandboxie would like to copy (and succeed if copy size limit is high enough) the file AAA.mp4 inside the box.
If AAA.mp4 has higher size than the configurer copy size limit, then sandboxie ask us if we allow the copy of the file (even if the ask message 2102 is disabled)
If we don't allow the copy, vlc.exe reads AAA.mp4 like normal (like a read only file).

AAA.mp4.mkv is read by vlc.exe in his box without the will of making a copy inside the box.

Is it a normal behaviour from sandboxie because of the "Desired Access: Generic Read/Write" asked by vlc for mp4 files (maybe it's a vlc's fault ?) ?
The copy, even for small files is uneeded.

Or maybe is it relative to the bug "File Copy Limit wraps at 4GB #526" ?

OS : windows10 x64 (all updates)
VLC : 3.12 x64
Sandboxie-Plus : 0.67

Thank you.

[DavidXanatos]

I would recommend to add MP4's to the list of files that are never to be migrated
see recent changelog:

• reworked file migration behaviour, removed hardcoded lists in favour of templates
  -- you can now use "CopyAlways=", "DontCopy=" and "CopyEmpty=" that support the same syntax as "OpenFilePath="
  -- "CopyBlockDenyWrite=program.exe,y" makes a write open call to a file that won't be copied fail instead of turning it read-only

so add
DontCopy=.mp4
DontCopy=.mp3
DontCopy=.avi
DontCopy=.mkv
etc..

to your sandboxie ini

earlier versions had a hardcoded list including many media files, that imho is problematic as people who want to run some media editor sandboxed will run against a invisible wall.
Hence the list was removed and replaced with a template with less entries using said new options parameters

I'll add an additional template to the next build containign the additional media files, called "Never migrate media files" or so such that for a user running against it it will be apparent whats the issue

[Rngexile]

Your workaround indeed works perfectly, thank you.

I've added this line in my video player dedicated box and everything runs fine for my needs (i prefer it stays specific to that box and that temporary case, because VLC can be useful to edit video files in other cases) :
DontCopy=vlc.exe,*.mp4

In the mean time, i've checked the behaviour of two others video players mpc-hc (one of the last 19.9.8.148) and the nightly build of VLC (4.0.0-dev-win64-e7022a7b) and both don't need the "Desired Access: Generic Read/Write", only the "Read", so they behave as expected to play videos *.mp4 files, inside or outside sandboxie, without the need to make a copy of the mp4 file inside the box.
I didn't find any bug report for VLC relatives to that but it seems it's adressed in the coming version.

I suppose sandboxie flagged the read+write desired access by current VLC as a need to make a copy of the mp4 file inside the box even if VLC didn't actually asked for a copy/write.
Feel free to close the issue if it's a normal behaviour of sandboxie, the workarounds are really easy (and even easier with your next template) and they won't even be needed in nexts versions of VLC.

Thank you !

[stdedos]

Or maybe is it relative to the bug "File Copy Limit wraps at 4GB #526" ?

Change rose from #441, but there was no intention to migrate files needed for read-only; but rather not run against an invisible wall (as mentioned).

I assume that, when VLC takes rw access, it blocks the deletion of the media played.
I also think that MPC-HC will not block it (and, as you mentioned, most likely it asks files for ro).

[DavidXanatos]

I assume that, when VLC takes rw access, it blocks the deletion of the media played

there are dedicated flags for that, which work with a ro open such that opening a file for writing is a very unelegant way of achieving that lock. Good that they fixed that in the upcoming 4.xx builds

[ganego]

This is not a vlc-only issue. I have this with PotPlayer too.
My solution was simply to set File Migration to like 10 KB and disable the messages for it. Sandboxie will still create the folder structure but no files.
If it can be fixed on player-level by using a different API-call, I should try to tell those guys, maybe they will change it too.