Resolve virtualized paths on Windows

[kaciula]

getApplicationSupportDirectory() from path_provider plugin returns a path such as C:\Users\John\AppData\Roaming\CompanyName\AppName and it works fine to save and read files using dart:io.

However, I see that the actual location for this directory is at a path such as C:\Users\John\AppData\Local\Packages\CompanyAppNameHash\LocalCache\Roaming\CompanyName\AppName

So it seems there is some abstraction/translation of paths being done by Windows OS. I understand it's called virtualization.

The issue I am running into is that I want to run an in-app executable and I need the actual real paths in order to run it. It seems that Shell and Process.run does not do the abstraction/translation part that happens when using dart:io and so the commands fail by not resolving the supplied paths.

I don't see any way to get the real paths to use in the shell commands so I'm thinking that maybe the plugin can do the path abstraction/translation similarly to how the dart:io package seems to be doing.

[alextekartik]

Thanks for the report. A similar issue was raised on this subject.

I think I understand the problem but I'm not sure where it fails. Can you clarify with a specific example ? Are you trying to run an .exe file, are you using an absolute path in the executable (preferred, could be get using `normalize(absolute(executable)) ?

[kaciula]

@alextekartik I'm shipping the app with a ffmpeg.exe executable that I am copying in the application support directory and trying to run it to process videos loaded by the user. I've tried running both with an absolute path and a relative one. For the relative path, I need to set the correct working directory but I don't know how to get the real path in the system.

The path_provider plugin reports the OS-provided paths and, as I've said before, these aren't the actual paths that can be used in a shell command. I didn't find a way to get the real paths for my app.

[alextekartik]

So multiple paths are involved:

1. path to the executable
2. path to the ffmpeg argument that could be file
3. working directory

process_run uses dart:io so I'm not sure where things could be fixed. It seems you manage the find the path to the executable. It is here where process_run does some trick (i.e. finding an exe file if you don't put the .exe extension).

Is it an issue in finding the path to the files that you send as arguments to ffmpeg ? Or finding a valid working path ?

What is the best way to reproduce the issue during development ?

[kaciula]

The paths that path_provider gives me work if I do dart:io operations but don't work if I supply them to process_run inside a command.

I'm not sure you can reproduce during dev. I only discovered the issue after publishing the app to Microsoft Store. As I mentioned before, Windows installs the app in a different place in the file system but reports virtualized paths to the app. Doing File operations works with these virtualized paths. They don't work however with process_run.

I'm wondering if it's a permission thing. Does process_run work in a separate isolate or a completely separate process?
As far as I understand it, WIndows containerizes the app so other processes cannot access the app's contents and private file system. Maybe that is why the paths aren't resolved correctly when running the shell command.

[alextekartik]

Does process_run work in a separate isolate or a completely separate process?

It uses io Process and runs in the main thread but spawn a separate child process (and asynchronously wait for its end)

As far as I understand it, WIndows containerizes the app so other processes cannot access the app's contents and private file system. Maybe that is why the paths aren't resolved correctly when running the shell command.

That's my fear too. If you have an opportunity to try a simple command such as dir <some_folder> that would be good to know

[kaciula]

@alextekartik I managed to make the shell commands to work by manually modifying the paths from the virtualized ones to the real ones. It's a hack and I'm not confident it will work on all Windows computers but it's the best I could come up with.

The basic gist is the following:

If a path starts with Platform.environment['APPDATA'] then I modify the path by replacing this first part with '${Platform.environment['LOCALAPPDATA']}\\Packages\\$packageName\\LocalCache\\Roaming'

This works for msix files installed from Microsoft Store but not if I run the app from an IDE or install the app as a standalone one outside of MS Store. In this case the paths should be left alone and not be modified.