"Open file in folder" does not always work on windows


the option “Open file in folder” in the PhotoStructure desktop version on Windows (Win 10, in my case) is supposed to open the selected asset in the explorer. For some assets, it does not work for me – instead the explorer opens on some unrelated folder (Documents).


If I copy the selected and run

explorer /select,"Z:\Lars\Google Pixel 3\Camera\PXL_20210402_162401445.MP.jpg"

the explorer opens with the file selected, as expected.

1 Like

Thanks for reporting this! I’ll try to reproduce it on my windows box now.

I’m switching the implementation to run a PowerShell scriptlet.

My hypothesis is that something in Windows Defender is grumpy about spawning explorer.exe , and if PowerShell does the fork, it’ll be considered “ok”.

I think I found the issue. I used procmon to find the command executed by PhotoStructure and it is

explorer.exe "/select,Z:\Lars\Google Pixel 3\Alle\PXL_20210309_141056049.jpg"

However, the right command is

explorer.exe /select,"Z:\Lars\Google Pixel 3\Alle\PXL_20210309_141056049.jpg"

(Note the placement of the first quote character)

In this case, the quotes are optional altogether, i.e.,

explorer.exe /select,Z:\Lars\Google Pixel 3\Alle\PXL_20210309_141056049.jpg

works, too (however, I don’t know whether there is a situation in which the quotes are needed).

I think the issue here is that Windows only has a single argument passed to process and each command makes up its own quoting rules.

Excellent debugging, thanks!

Yup! Powershell escaping normally uses the backtick. I found yesterday via trial and error that if I want PowerShell to spawn explorer with a path with a single quote, I have to double up the single quote (sql-style!?!), and that backtick escaping was ignored.

I’ll verify the first double-quote placement is correct this morning.

Thanks again!

1 Like

Yes, PowerShell escaping is unusual. Do you know https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_quoting_rules?

No, thanks for that link! I built the current string escaping using a different microsoft reference.

I just checked the code:

async function explorerSelect(file: PosixFile): Promise<boolean> {
  // The quotes around the paths make whitespace get handled correctly:
  return run("explorer.exe", ['/select,"' + file.nativePath + '"'])

So… those quotes in the wrong place seem to have been “helpfully” added by Node. Forking via PowerShell should avoid those shenanigans.

Here’s the new implementation:

async function explorerSelect(file: PosixFile): Promise<boolean> {
  const path = file.nativePath
    // Double-quotes are not allowed in windows paths, but just to be safe:
    .replace(/"/g, "")
    // PowerShell supports escaping single quotes with two single quotes.
    // See https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_quoting_rules
    .replace(/'/g, "''")
  try {
    await PowerShell.instance().execute(
      `start explorer.exe -ArgumentList '/select,"${path}"'`,
    return true
  } catch (err) {
    logger().warn("explorerSelect(" + file + ") failed", err)
    return false

And proof:

1 Like

@mrm You can slightly improve performance if you use PowerShell’s cmdlet Invoke-Item $path instead of spawning separate explorer.exe process

Rock on, I just made that change. Thanks!

Actually, that opens the file in the default app. I need to open explorer.exe with the given file selected.

1 Like

@mrm I just realized this way allows to open the folder but cannot highlight the selected file, so your previous way is better. Sorry for the confusion

No problem: keep the suggestions coming! :beers:

1 Like

@Lars_Noschinski this should be fixed in the new alpha: does it work on your machine?

It seems so, yes. Tried a few images with spaces in them, for all of them it worked.