RunAs() doesn't work with long path or Temp dir?

[E1M1]

Following example does NOT work:

RunAs("user", @ComputerName, "pass", 1, "C:\Documents and Settings\rain\Local Settings\Temp\handyman.exe")

But this 2nd example works perfectly

RunAs("user", @ComputerName, "pass", 1, "C:\windows\notepad.exe")

Also this example works

Run("C:\Documents and Settings\rain\Local Settings\Temp\handyman.exe")

Why 1st example (code/script) doesn't work?

However 2nd example works which shows that there's no problem in user/password.

Also 3rd example is working which shows that file exists.

Edit:

if I debug with FileExists() then it returns 1

an other thing i found was that if I moved handyman.exe from temp dir to C:\ then it worked.

I can't find any reason why 1st code doesn't work, I would like to know if you can find anything?

Edited January 23, 2010 by E1M1

[Richard Robertson]

Spaces cause problems in paths. Double quote the path.

Run('"C:\Documents and Settings\rain\Local Settings\Temp\handyman.exe"')

[E1M1]

no space is not the problem.

This also doesn't work

RunAs("user", @ComputerName, "pass", 1, "C:\WINDOWS\Temp\handyman.exe")

Edit:

But This works fine

RunAs("user", @ComputerName, "pass", 1, "C:\WINDOWS\handyman.exe")

any ideas now? or is it just bug?

Edited January 23, 2010 by E1M1

[Richard Robertson]

What I said is true, spaces do cause problems.

Perhaps the files don't even exist at the destination. Try checking to see if they exist first, and give a message box showing if it is found or not. See if this helps.

Also look at file permissions. Make sure the user account has permission to access those folders.

Edited January 23, 2010 by Richard Robertson

[E1M1]

normal run works fine

Perhaps the files don't even exist at the destination.

Can you read what I written?

if I debug with FileExists() then it returns 1

Also look at file permissions. Make sure the user account has permission to access those folders.

every one has read only permission for "c:\windows\temp"

What I said is true, spaces do cause problems.

if you would bother reat what I posted above then you should have seen this:

no space is not the problem.

This also doesn't work

RunAs("user", @ComputerName, "pass", 1, "C:\WINDOWS\Temp\handyman.exe")

[Richard Robertson]

I didn't say spaces were the only problem. I said they can be one.

You edited that top post 15 minutes ago. I don't remember the FileExists line being part of the post originally.

Have you tried setting the working directory to see if that helps?

Also, why are you manually typing the temp path? Why not use @TempDir & "\handyman.exe"?

[E1M1]

You edited that top post 15 minutes ago. I don't remember the FileExists line being part of the post originally

I edited because i mistakenly posted porking passwords/users

Have you tried setting the working directory to see if that helps?

I gonna try if it helps but, I don't belive it does cuz autoit doesn't even try run it.

@TempDir & "\handyman.exe"

tried this, it didn't help me

Can you try this?

You gotta use user a that has admin rights and user b which is normal user.

now copy file.exe to c:\windows\temp (you can also try with @tempdir which leads to user a temp dir)

under user a try run file.exe as user b

results?

paths you had?

[Mat]

Why don't you use the FileGetShortName function?

FileGetShortName(@TempDir & "\handyman.exe")

[Richard Robertson]

Well, you really shouldn't be writing to C:\Windows\Temp. Use All Users's temp folder instead and see if it works.

[Monolith]

Well, you really shouldn't be writing to C:\Windows\Temp. Use All Users's temp folder instead and see if it works.

Not the best idea to write to systems temp , specially if you do not have perms as most local users don't.

@E1M1

Have you tried changing the "logon_flag" value? i would try "0"

and try incorporating the method Matt suggested.

$file1 = FileGetShortName(@tempDir & '\handyman.exe')

$usr = "username"
$pwd = "password"

RunAs($usr, @ComputerName, $pwd, 0, $file1)

[E1M1]

Why don't you use the FileGetShortName function?

FileGetShortName(@TempDir & "\handyman.exe")

Just tried. didn't help me.

Not the best idea to write to systems temp , specially if you do not have perms as most local users don't.

I have main program running under user "SYSTEM" and i want to execute it's plugin under x user

@E1M1

Have you tried changing the "logon_flag" value? i would try "0"

I have tried all flags but they doesn't make it work.

and try incorporating the method Matt suggested.

$file1 = FileGetShortName(@tempDir & '\handyman.exe')

$usr = "username"
$pwd = "password"

RunAs($usr, @ComputerName, $pwd, 0, $file1)

this code also didn't work, its actually same as mine, just other formatting.

but still

Run(FileGetShortName(@tempDir & '\handyman.exe'))

works fine

just run as is problem.

I am using autoit 3.3.0.0 and Win xp pro sp2

Edit: updated it , didnt help.

and I also found that if i run it as system service then it somehow works but, file starts and soon as it started it says: "AutoIt error","Unable to open the script file", and soon as i click ok it(autoit exe that executed with runas()) closes itself

Edited January 24, 2010 by E1M1

[Richard Robertson]

That unable to open script file means your antivirus is blocking it, or file permissions are blocking it.

[E1M1]

That unable to open script file means your antivirus is blocking it, or file permissions are blocking it.

if my main program runs under SYSTEM and I use runas() then does command runas already run with user's permissions or permissions applies ony to program?

then does unable to open script file mean that autoit exe is executed but since it runs as limited user it doesn't have right to read acript from itself?

[Richard Robertson]

if my main program runs under SYSTEM and I use runas() then does command runas already run with user's permissions or permissions applies ony to program?

then does unable to open script file mean that autoit exe is executed but since it runs as limited user it doesn't have right to read acript from itself?

Yes, that is very likely what is happening. That's why I suggested the All Users' temp folder. Edited January 24, 2010 by Richard Robertson