Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proc.open_files() limiting results on Windows #1020

Closed
osstony opened this issue Apr 25, 2017 · 10 comments
Closed

proc.open_files() limiting results on Windows #1020

osstony opened this issue Apr 25, 2017 · 10 comments

Comments

@osstony
Copy link

osstony commented Apr 25, 2017

proc.open_files() seems to only be returning files located on my C: drive but no files located on any other drives. I found this out by iterating over every running proc, calling open_files and comparing the results to what is spit out of executing the handle program located at https://technet.microsoft.com/en-us/sysinternals/handle.aspx.

I don't have any further details other than the open_files returned always only exist on my C: drive and no other available drives.

If you need further details please let me know.

@giampaolo
Copy link
Owner

giampaolo commented Apr 25, 2017

open_files on Windows is basically unreliable and a pain in the ass historically, see the red warning here:
https://pythonhosted.org/psutil/#psutil.Process.open_files
...and:
#597
I'm not surprised this is yet another problem I wasn't aware of.
Realistically I think I'll just add another warning to the doc, but I won't invest time into fixing it because I consider it a lost cause.

CC @mrjefftang

giampaolo added a commit that referenced this issue Apr 25, 2017
@osstony
Copy link
Author

osstony commented Apr 25, 2017

It's too bad it's such a pain. It's a great feature to use when Windows is doing dumb things and keeping open file handles on things it shouldn't need too.

If I have some spare time at some point maybe I can take a look at this specific bug.

Thank you for your hard work on this project!

@mrjefftang
Copy link
Collaborator

What version of Windows are you running on?

@osstony
Copy link
Author

osstony commented Apr 25, 2017

Windows 10

@osstony
Copy link
Author

osstony commented Apr 25, 2017

The simple test I used is to open a folder in a drive other than C: using explorer. The path to that folder should show up in the open file handles for explorer.exe.

@mrjefftang
Copy link
Collaborator

Strange, that shouldn't be missing file handles unless they are network drives.

The reality is that open_files was hacked together to make it work. There's a proper solution using Windows APIs that are available in 7+ and drop support for prior versions.

@giampaolo
Copy link
Owner

Jeff, what about it? If you're sure about it I'm all for dropping the hack currently in place and support Win 7 only.

@mrjefftang
Copy link
Collaborator

I don't remember the exact API calls at the time but I remember it only working on Windows 7+ when I tested it. And at that point in time, I needed to support WinXP for a project that relied on psutil. I might have documented it in one of the previous PRs/issues.

I don't have time to work on it but I believe it would be straight forward for someone to implement this using the right APIs.

@akiross
Copy link

akiross commented Jun 7, 2018

Hello, I am starting to look into this matter as I would like to accurately observe opening/closing events on windows, but I am not familiar with Windows API. Is it possible that the API @mrjefftang was mentioning is TDH? An answer on StackOverflow refers to it as something introduced in Vista/7.

@giampaolo
Copy link
Owner

Looking back at this because I am rewriting open_files() code on Windows: it seems that psutil is able to list files living on drives other than C:\ after all. I've just created a file on another drive (E:) and it shows up. The doc mentions this limitation but it appears it's either wrong or outdated. Closing this out.

giampaolo added a commit that referenced this issue Jan 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants