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

Bug
1

Hi,

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).

grafik

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
2

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

3

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”.

4

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.

5

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
6

Yes, PowerShell escaping is unusual. Do you know about Quoting Rules - PowerShell | Microsoft Learn?

7

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}"'`,
      SimpleParser
    )
    return true
  } catch (err) {
    logger().warn("explorerSelect(" + file + ") failed", err)
    return false
  }
}

And proof:

image
image918×416 19.1 KB

1 Like
8

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

9

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
10

@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

11

No problem: keep the suggestions coming! :beers:

1 Like
12

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

13

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