Why would os.path.exists("C:\\windows\\system32\\inetsrv\\metaback") return False even when it exists?

Question

I've got a python program which is supposed to clean up a number of directories and one of them is C:\windows\system32\inetsrv\metaback; however, os.path.exists() returns False on that directory even though it exists (and I have permissions to access it).

What's interesting also is that the tool windirstat completely misses it as well.

Can anyone think of a reason why this might be and what's another way I could check to see if it exist? I can't even seem to run os.listdir() on it.

Update: os.path.exists() works on this directory if the Windows box is 32-bit, but not if it is 64-bit. Also shows up properly in windirstat on a 32-bit box.

Asinine

Is it even a directory that you can write to? Access != write/read, so this might explain why you can't list it. – Interlaken

Can you shell out to a command prompt and navigate to it from there? – Gigi

I don't think moving this to serverfault would be appropriate, because it isn't a permissions problem. – Amboina

Also, the version of Windows may be quite important, so please include that in your question. – Amboina

Answer 1

This is redirection of system folders at work. When a 32-bit process is running on a 64-bit version of Windows and uses the path %WINDIR%\System32, Windows substitutes %WINDIR%\SysWow64.

The function is returning false to tell you that C:\windows\syswow64\inetsrv\metaback does not exist, and it most likely is absolutely correct.

Try instead:

os.path.exists("C:\\windows\\sysnative\\inetsrv\\metaback")

Amboina

Answer 2

Windows x64 security is quite a bit tighter than windows x86; especially under the current release OSes (7, 2008).

Sounds like your script doesn't actually have the permissions it needs to run. Generally speaking MS locked down quite a few directory paths (like c:\inetpub) which require elevated priviledges in order to perform any actions.

There are huge reasons for this and it's generally considered a very good thing.

I believe you'll want to mark your script (or whatever executes it) as "Run as administrator" in order to give it the elevated control. Of course, this may require you to confirm execution via the UAC.

For further information, go to serverfault.com and ask there.

Irretentive

It's not a permissions problem, it's a path interpretation problem. – Amboina

Also, Windows 2008 isn't the latest version, it's the server version of Vista. – Amboina

marketing aside, 7 and R2 are amazingly close to Vista under the hood. – Irretentive

"Amazingly close", hmmm, I wouldn't go that far. – Photolysis

@Chris: Not in terms of default permissions, which was IIRC your entire answer, yes? – Amboina

Guys: Vista was a radical change from XP in both usability and security. 7 dialed back on the UAC triggers and expanded the feature set. Fully half of those "features" were tweaks to existing items under the Vista kernel. Basically, they completed what they had started to do. My "amazingly close" statement is based on the fact that while Vista was a major change from XP, 7 was a point release (vista = 6.0, 7 = 6.1). Does this mean there aren't differences? No. – Irretentive

However, if you perform even a cursory review of the change list from MS for 7/R2 you're going to see a tremendous number of "improvements in..." statements. The point of my answer was simply to say that the x64 OSes (Vista/7/2008/R2) implemented far more security changes than the x86 counterparts. Which the OP might need to take into consideration as he tests his app in both environments. Especially considering he is looking to "clean up" files in those protected directories. – Irretentive