run dopus.exe with non-admin permissions,
then run dopusrt.exe /info a.txt,paths , but don't work (would not create a.txt)
is this designed the way on purpose?
I think it is unreasonable 
That command requires two-way communication, and a non-elevated process cannot talk to an elevated process.
But DOpusRT.exe has a built-in way to run things without elevation from an elevated context; /runstd:
"C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /runstd "C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /info "C:\dir\a.txt",paths
1 Like
the /runstd work, but if the dopusrt.exe is non-elevated,how to run /info with an elevated dopus.exe?
so
is there a method to run dopusrt.exe /info , regardless of whether dopus.exe is elevated or not ?
if not, would you consider to add this feature ?
You would have to run dopusrt.exe via elevation in that case.
But you should not run dopus.exe elevated in the first place: Why NOT to run Opus as Administrator under UAC
I have a advise : add /runstd <dopusRT_path> automaticly when run dopusrt /info, as following table show:
| dopusrt | dopus | add /runstd <dopusRT-path> before /info |
|---|---|---|
| elevated | non-elevated | yes |
| elevated | elevated | no |
| non-elevated | non-elevated | no |
| non-elevated | elevated | no and output error to console: can not communicate with higher permissions program |
Then it would break if dopus.exe was elevated (and we are not going to test for that and complicate things to such a degree; issues like this are a completely normal part of how UAC works and something you should avoid doing in the first place).
Why are you randomly running some things and not others elevated in the first place? And why are the elevated things changing?
Neither program should be elevated in any normal situation, and the thread has already gone from being about one program being elevated to the other. Fix the fact either is elevated at all instead of worrying about what happens when one thing or the other is.
for some users,dopusRT.exe will be called by external programs, for example : autohotkey or batch script,
those scripts have different permissions,
so dopusRT.exe is not always called with same permissions,
it is inconvenient for user to check whether dopusRT and dopus have different permissions and decide to add /runstd or not ,
so why not handle it for user automaticly?
It's up to those things (or the scripts you write) to run the program without elevation, the same as with any other program they run.
We've provided /runstd for this, which is more than the OS itself does. We don't plan to make it easier than that as this is a much more general problem, not just one involving dopusrt.exe/dopus.exe, and one you'll need to solve for everything else that you run as well, if you can't control the context that your code is launching things from.
(Given Opus shouldn't be run elevated, you could also always use /runstd, if you want to keep things simple on your side of things.)
1 Like
ok,thank you!
are there miscrosoft official documents about the limitation non-elevated process cannot talk to an elevated process?
In order to bypass the limitation when retrieving file and folder information, I have a idea:
add a options to let dopus.exe save these information to local file automaticly, like this:
or would you consider to add a script event that be triggered when lister tabs change so that users can achieve that by write scripts
thanks!