Process exe should not resolve symlinks + enhanced cmdline guessing

[giampaolo]

From g.rodola on August 14, 2012 13:29:57

This is both a bugfix and an enhancement.

THE BUGFIX

As explained here: 
https://groups.google.com/forum/?fromgroups#!topic/psutil/oxAd0BuAzt0%5B1-25%5D
 ...the original exe gets resolved via os.path.realpath():

> Also, I heard a rumor that we tried to upgrade but couldn't because 
> .exe now follows hard-links on Windows. Earlier .exe would return the 
> path the process was started from, but now it returns the actual path 
> of the executable. Any idea where that behavior came from? Would it be 
> possible to expose both? 

This should be avoided and the original unresolved path be returned instead.
It is then up to the user to decide whether to resolve the path or not.


THE ENHANCEMENT

exe property is implemented such that if the original get_process_exe() call is 
not able to determine process executable we try to guess it from the cmdline.
get_process_exe() can raise AccessDenied tough, and we let that propagate 
immediately.
Instead we should:

- catch AccessDenied
- try to guess exe from cmdline as last resort
- if that didn't produce any result then raise AccessDenied

The test script below on Linux shows that by doing so we can determine twice 
the amount of exe(s) than before.
Similar results are likely to apply to other platforms as well.


found = 0
for p in psutil.process_iter():
    try:
        p.exe
    except psutil.AccessDenied:
        pass
    else:
        found += 1
print found


Both issues are now fixed in r1513 and r1514

Original issue: http://code.google.com/p/psutil/issues/detail?id=316

[giampaolo]

From g.rodola on August 16, 2012 09:41:08

Status: Fixed

[giampaolo]

From g.rodola on March 02, 2013 04:12:21

Updated csets after the SVN -> Mercurial migration: r1513 == revision ???