0

The Synaptics Touchpad Helper runs at user logon as a scheduled task. The command line configured to run the executable is...

"\Program Files\Synaptics\SynTP\SynTPEnh.exe"

As you may assume, it is installed on the C:\ drive. The task launches the process without an issue, despite that it seems malformed at first glance. Can someone explain exactly how a process is able to run from a path such as this without specifying the drive letter?

scheduled task command line properties

6
  • I'm sure, that's the command line from the task copied verbatim.
    – Bigbio2002
    Jul 6, 2015 at 14:41
  • Pics. It happened.
    – Bigbio2002
    Jul 6, 2015 at 14:43
  • put your mouse in the Program/Scrpt box, and hit the Home button. are there characters to the left in the textbox that we can't see? Jul 6, 2015 at 14:44
  • @FrankThomas try it you'll see it works as bigbio says and the q is y
    – barlop
    Jul 6, 2015 at 14:56
  • @FrankThomas no, there aren't. I'm sure this is perfectly valid behavior, I want to know why it functions like this.
    – Bigbio2002
    Jul 6, 2015 at 14:59

2 Answers 2

2

Every process has a current drive and directory, the process that runs the scheduled jobs is no different.

When a process accesses a file, if no drive and directory is specified, Windows will assume the current drive and directory. If a directory is specified, but no drive, Windows will assume the current drive.

In this case, since there wasn't a drive specified in the path, Windows will assume the current drive of the scheduler process, which will almost certainly be the system drive - typically C:

3
  • Do you have a reference for this?
    – Bigbio2002
    Jul 6, 2015 at 16:41
  • there is also a system drive variable %SYSTEMDRIVE% but to prove it uses it, i'm not sure how one would. One could prove that it detects the system drive though, by running it from other system drives. It seems to me obvious that it's using the system drive 'cos I can't see any other methods it would or could use. But even then, whether it directly uses that %SYSTEMDRIVE% variable or not is another matter
    – barlop
    Jul 6, 2015 at 20:59
  • There must be some Windows documentation on this somewhere...
    – Bigbio2002
    Jul 7, 2015 at 13:54
-1

well, it obviously assumes C:\ I don't think it's malformed, it has been possible to do that in (proper) DOS that's going back over 15 years. In the DOS case, it looks at what drive you are currently on so if you're in C:\windows and you say \blah\bleh then it runs c:\blah\bleh If you were on D:\> and you did \blah\bleh it assumes you mean d:\blah\bleh it's a relative path where the path is relative to the directory you're in.. That's the case for CMD.exe and for DOS. The task scheduler may have some setting like start in, that tells it, or maybe it just assumes C. But there's nothing malformed and it's not strange. It's a relative path. Just as in a sense C:\windows\system32>calc.exe may be relative. Or C:\>windows\system32\calc.exe which is different from C:\blah>\windows\system32\calc.exe Doing \windows works from whichever directory you are in. Whereas doing windows without the preceding backslash means windows must be a subdirectory of the current directory.

Somebody may give a better answer answering specifically for task scheduler but anyhow.

4
  • 1
    You're not incorrect, but I'm curious as to exactly how it works in the task scheduler. What makes it assume the C:\ drive? Why doesn't it error? Why is it valid?
    – Bigbio2002
    Jul 6, 2015 at 14:40
  • I don't know that much about task scheduler but probably something trivial, so maybe not even a built in option, but something even more trivial, like if Windows is running from C:\ then it assumes C:\. And then you can see if there is any change if you change the value in 'start in'.
    – barlop
    Jul 6, 2015 at 14:48
  • also another possibility is the environment variable %SystemDrive% which is C:
    – barlop
    Jul 6, 2015 at 14:55
  • It's definitely not "start in", as I just tried changing it to another drive and it still worked. SystemDrive doesn't look very changeable. It's not listed in environment variables in the environent variables window, though SET lists it. Really it's very likely that if windows is on some other drive it'll go there. But we can't test that unless we have windows on another partition like that.
    – barlop
    Jul 6, 2015 at 15:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .