Starting an app from symbolic link starts the app from orig

[rvheddeg]

When I create a symbolic link (mklink /D "link_dir" "orig_dir") to a directory whit an executable, starting this executable starts it always from the original directory and not from the symbolic link.

In contrast, when I start the same application from a command window (in the link_dir), the application directory is the symbolic link.

This means that there's a difference in execution between TC and the command window...

I also think that this regression is introduced in the latest version, and that everything was correct in version 8.

[MVV]

Can't confirm, process command line contains proper program path (though image name is the link target as it should).

Are you sure that TC has enough permissions to execute your link? Otherwise it may try to read link target...


Added:

Please ignore, tested another thing.

[gdpr deleted 6]

Can't confirm, process command line contains proper program path (though image name is the link target as it should).

Are you sure that TC has enough permissions to execute your link? Otherwise it may try to read link target...

I can confirm the issue. Tested both with a batch file (i.e., echo %cd%) as well with an executable. When executing either with TC from the symbolic link dir, TC does set the current working directory to the sym link target directory. This is indeed different from both Windows Explorer as well as command line (which leave the current directory as is, i.e., the symbolic link dir path).

@mvv, what did you do precisely?

[gdpr deleted 6]

Update: It seems the issue only manifests if the link target dir is specified using a relative path when creating the sym link dir as it seems.

If i have a directory X:\targetdir and i do

Code: Select all

X:\> mklink /d linkdir targetdir

and start my test batch file (or test executable, i did both) with TC from within x:\linkdir, then the issue occurs as described.

However, if i create the sym link dir using an absolute path

Code: Select all

X:\> mklink /d linkdir X:\targetdir

the issue does not occur.

[MVV]

Well, I've tested it once again.

1. I've created symlink D:\_\notepad.exe for C:\Windows\notepad.exe and started it from TC. Process Hacker shows command line:

Code: Select all

"D:\_\notepad.exe" 

And current directory:

Code: Select all

D:\_\

Works as expected.

2. I've created symlink D:\_\link.exe for D:\_\cmdline.exe and started it from TC, command line was:

Code: Select all

"D:\_\link.exe" 

And working directory was:

Code: Select all

D:\_\

Works as expected.

[gdpr deleted 6]

Well, I've created a symlink D:\_\notepad.exe for C:\Windows\notepad.exe and started it from TC. Process Hacker shows command line:

Code: Select all

"D:\_\notepad.exe" 

And current directory:

Code: Select all

D:\_\

Works as expected.

See my update in my last comment. Also, it's about symbolic directory links, not file links

[MVV]

Well, my mistake, report was really about directory symlinks, so I've tested them.

1. I've created an absolute symlink D:\_\projects_link for dir with cmdline.exe file and started D:\_\projects_link\cmdline.exe.
Process command line:

Code: Select all

"D:\_\projects_link\cmdline.exe" 

Current directory:

Code: Select all

D:\_\projects_link\

Works as expected.

2. I've created a relative symlink D:\_\projects_link for same dir with cmdline.exe file and started D:\_\projects_link\cmdline.exe.
Process command line and working path are really incorrect, process has been started using symlink target from its directory!

[ghisler(Author)]

This isn't a bug, it's intentional, because launching of EXE files within links fails with ShellExecuteEx. From the history:
05.08.16 Fixed: Microsoft has brought back a bug they fixed long ago in IE10: ShellExecuteEx fails if the launched EXE is in a path containing relative links -> use old workaround to resolve path ourselves (32/64)

[MVV]

ghisler(Author),
But why do you change working directory too? And, how does Explorer start such links?

[gdpr deleted 6]

@ghisler,
note that both explorer and cmd.exe work the same and as expected; i.e., when a program is started from within a symlink directory then the working directory is exactly that symlink directory. It is TC which is showing behavior different from the OS (Explorer as well as command line shell).

The behavior of the OS is the guiding standard here. If TC is not executing executables in the same way as Explorer and cmd.exe do, then this is not a problem with the OS but a problem with TC...

[MVV]

ghisler(Author),
Can you use CreateProcess when ShellExecuteEx fails? I.e. if execution fails, you check if there are links in the path and then try CreateProcess (I would even always use CreateProcess for executables)... It will be a much better behaviour than starting symlink with original app's path as %0 and unexpected working directory which is simply wrong...

BTW I have Windows 7 with IE11 and both ShellExecute/ShellExecuteEx work just fine for this symlink, but TC still starts link target. So I think that problem that TC tries to avoid is much less serious than one that TC brings.

[ghisler(Author)]

No, I can't use CreateProcess, because it doesn't support elevation (run as admin) if the EXE requests it. I could launch the original EXE but with the path set to the symlink directory, though.

[ghisler(Author)]

In TC 9.10, I'm now setting the current directory when launching to the link directory, not the link target. Please test it!

[rvheddeg]

I have tested it using a batch file and an executable made by Delphi.
Both worked correctly in my tests.

Thx