c:\windows\system32\dllcache inaccessible

You want to talk about Far Manager, but don't know where to turn?
Locked
Pooman
Posts: 6
Joined: Sun Jun 12, 2005 10:55 am

c:\windows\system32\dllcache inaccessible

Post by Pooman »

Under Windows 2003 Server the "dllcache" directory is hidden unless running cmd.exe or Windows File Explorer. This must be some anti-malware feature but it's very annoying. All other programs like Far, Cygwin bash, and even some disk defraggers don't see the directory at all. Have anyone else experienced this or know some way to disable this security feature?
pp
Posts: 25
Joined: Wed Mar 23, 2005 1:54 pm
Location: Czech Republic
Contact:

Post by pp »

Maybe stupid question, but did you set "show hidden and system files" on? Can you simply "cd c:\windows\system32\dllcache"?
sicvolo
Posts: 9
Joined: Fri Apr 21, 2006 11:46 pm

Post by sicvolo »

Most likely your server has the new feature of Win 2003 turned on that
forbids even seeing the folders that you do not have access to via ACIs
Pooman
Posts: 6
Joined: Sun Jun 12, 2005 10:55 am

Post by Pooman »

Before jumping into the conclusion that Windows Server 2003 is doing some kind of parent process security check I want to provide some more observations.

This system is a x64. It has C:\windows\System32 and C:\windows\SysWOW64 directories.

Far behavior:

Using Process Monitor from Sysinternal Far tries to open the SysWOW64 when I'm actually trying to open the System32 directory.

Running CMD and bash shells under Far:

"dir c:\windows\system32" shows up an open to "c:\windows\syswow64" in Sysinternal.

Running CMD shell from under other processes (e.g. explorer, task manager, process explorer):

"dir c:\windows\system32" actually resolves correctly.

Running Cygwin bash shell from under other processes (e.g. explorer, task manager, process explorer):

"dir c:\windows\system32" silently resolves to SysWOW64 directory.

Now this is a problem. Something is silently replacing queries to System32 to SysWOW64 as captured by Process Monitor. This implies that the replacement had to have come from non-kernel space because the directory asked for had already changed before reaching the kernel.

My current thinking is perhaps Microsoft changed kernel32.dll or added some DLLs which do Win32 to Win64 compatibility translations. The problem is how to turn this feature off, or how can programs like FAR work around it.
Pooman
Posts: 6
Joined: Sun Jun 12, 2005 10:55 am

Post by Pooman »

Aha! Windows x64 compatibility crap!

Far needs to be modified so that the thread that gets the current directory list is expected to call Wow64DisableWow64FSRedirection(). The simpler fix is to recompile Far for 64-bit Windows to avoid the WOW mess.

http://support.microsoft.com/kb/942589
User avatar
t-rex
Admin
Posts: 417
Joined: Sun Mar 20, 2005 6:10 pm
Location: Ashdod
Contact:

Post by t-rex »

Pooman
There is an x64 version of FAR.
User avatar
NiteSHdw
Posts: 3
Joined: Sat Nov 04, 2006 8:48 pm

Post by NiteSHdw »

I found a build of 1.71 that's x64, but I can't find any x64 builds of 1.8. Are there any x64 builds of 1.8, or is preferable to just stick with 1.71 for now?
User avatar
t-rex
Admin
Posts: 417
Joined: Sun Mar 20, 2005 6:10 pm
Location: Ashdod
Contact:

Post by t-rex »

NiteSHdw
If you can't build 1.80 on your own, you shouldn't use it at the moment.
Locked