Python cant see files or folders in C:\Windows\System32\GroupPolicy - windows

I'm running into a problem where python is unable to see folders or files which do exist on the computer. I have already ensured the path has no symbolic links in it and that I have full control on the NTFS file permissions. I have even removed any hidden attributes. Below is the script I am using and its output:
import os
path = 'C:\\Windows\\System32\\GroupPolicy\\Machine'
print path
test = os.path.exists(path)
print test
C:\Windows\System32\GroupPolicy\Machine
False
I am unsure why it is returning False when I have ensured the folder does exist. If I remove "\Machine" from the path, it returns True. I have verified the following command works from a command prompt:
if exist c:\Windows\System32\GroupPolicy\Machine echo found
Any advice on how to get this working in python would be appreciated. Here is the version of python I am using:
Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win32

Alright, after some digging, found it is nothing to do with permissions but has to do with File System Redirection. As I am using the x86 version of python on a Windows x64 (using x86 as I am using py2exe), Windows is redirecting any queries on System32 and subdirectories to SysWOW64. This means I was actually querying "C:\Windows\SysWOW64\GroupPolicy\Machine" which did not exist.
To fix this, I found how to disable the File System redirection using the recipe found here: http://code.activestate.com/recipes/578035-disable-file-system-redirector/
Here is my final code which now works to disable the redirection and allows opening and querying of files in System32 on a 64 bit machine.
import ctypes
class disable_file_system_redirection:
_disable = ctypes.windll.kernel32.Wow64DisableWow64FsRedirection
_revert = ctypes.windll.kernel32.Wow64RevertWow64FsRedirection
def __enter__(self):
self.old_value = ctypes.c_long()
self.success = self._disable(ctypes.byref(self.old_value))
def __exit__(self, type, value, traceback):
if self.success:
self._revert(self.old_value)
disable_file_system_redirection().__enter__()
import os
path = 'C:\\Windows\\System32\\GroupPolicy\\Machine'
print path
test = os.path.exists(path)
print test

Related

Error while generating grpc files (--grpc_out: protoc-gen-grpc: Plugin failed with status code 1.)

I’m trying to run the following command to generate grpc files:
protoc --proto_path=$PROTO_PATH --plugin=protoc-gen-grpc=$PLUGIN_GRPC --grpc_out=$OUT/grpc $PROTO_FILES
This results in the following error:
/Users/MYUSERNAME/Downloads/protoc-gen-grpc-java-1.48.1-osx-aarch_64.exe: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable
--grpc_out: protoc-gen-grpc: Plugin failed with status code 1.
I made sure the file from the error message is located at that path and has also the correct permissions.
-rwxrwxrwx# 1 MYUSERNAME staff 6334176 10 Aug 00:03 protoc-gen-grpc-java-1.48.1-osx-aarch_64.exe
I also tried running the command as sudo.
Generating java or kotlin files with --java_out=$OUT/java --kotlin_out=$OUT/kotlin
works perfectly fine, so the problem is --grpc_out=$OUT/grpc
I also downloaded multiple versions of the protoc-gen-grpc-java-1.48.1-osx-aarch_64.exe file but it always results in the same error. I also tried replacing all path variables (e.g. $PROTO_PATH) with their corresponding values, without any effect. I’m using MacBook with M1Pro chip.
The problem is that M1 Macs aren't supported. They have copied over the osx-x86_64 binary and renamed it for osx-aarch_64 as a workaround to make it easier to run with Rosetta. See here for where that change was made and here for the full conversation about supporting M1 Macs.

Why doesn't stack (installed by ghcup) find msys (installed by ghcup) on Windows

On my Windows 10 system, I set up Haskell using GHCup. I installed ghc, cabal and stack. Now I am trying to install a package depending on network. Network needs msys for building, but it is obviously not detected:
C:\Users\Michael\source\repos\dummy>stack install network
network> configure
network> [1 of 2] Compiling Main ( C:\Users\Michael\AppData\Local\Temp\stack-c2e699ee2698c622\network-3.1.1.1\Setup.hs, C:\Users\Michael\AppData\Local\Temp\stack-c2e699ee2698c622\network-3.1.1.1\.stack-work\dist\274b403a\setup\Main.o )
network> [2 of 2] Compiling StackSetupShim ( C:\Users\Michael\AppData\Roaming\stack\setup-exe-src\setup-shim-Z6RU0evB.hs, C:\Users\Michael\AppData\Local\Temp\stack-c2e699ee2698c622\network-3.1.1.1\.stack-work\dist\274b403a\setup\StackSetupShim.o )
network> Linking C:\Users\Michael\AppData\Local\Temp\stack-c2e699ee2698c622\network-3.1.1.1\.stack-work\dist\274b403a\setup\setup.exe ...
network> Configuring network-3.1.1.1...
network> setup.EXE: The package has a './configure' script. If you are on Windows, This
network> requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. If you
network> are not on Windows, ensure that an 'sh' command is discoverable in your path.
network>
Although documentation seems sparse on it ("you might want to look into extra-path"), I configured stack seemingly correct to have the Shell provided by MSys2 in the path:
C:\Users\Michael\source\repos\dummy>type c:\Users\Michael\AppData\Roaming\stack\config.yaml
templates:
params: null
system-ghc: true
install-ghc: false
skip-msys: true
extra-path:
- 'C:\ghcup\msys64\usr\bin'
- 'C:\ghcup\msys64\mingw64\bin'
extra-include-dirs:
- 'C:\ghcup\msys64\mingw64\include'
extra-lib-dirs:
- 'C:\ghcup\msys64\mingw64\lib'
The MingW path is correct. A more direct test of stack shows that the path isn't applied:
C:\Users\Michael\source\repos\dummy>stack exec sh
Executable named sh not found on path: [".","C:\\Users\\Michael\\source\\repos\\dummy\\.stack-work\\install\\38482417\\bin","C:\\Users\\Michael\\AppData\\Roaming\\stack\\snapshots\\6c93f868\\bin","C:\\Users\\Michael\\AppData\\Roaming\\stack\\compiler-tools\\x86_64-windows\\ghc-8.10.7\\bin","C:\\ghcup\\bin",...,"C:\\WINDOWS\\system32","C:\\WINDOWS","C:\\WINDOWS\\System32\\Wbem","C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\",...,"C:\\Program Files\\Git\\cmd",...,"C:\\ghcup\\bin"]
I redacted parts of the path output that are unrelated to the problem. Obviously, no mention of the MSys directory here. Also obviously, sh.exe is not found, although it is where I expect it:
C:\Users\Michael\source\repos\xilinx>dir c:\ghcup\msys64\usr\bin\sh.exe
Datenträger in Laufwerk C: ist Windows
Volumeseriennummer: xxxx-xxxx
Verzeichnis von c:\ghcup\msys64\usr\bin
19.05.2021 07:47 2.201.842 sh.exe
1 Datei(en), 2.201.842 Bytes
0 Verzeichnis(se), ??.???.???.??? Bytes frei
This is a known issue with Stack. In windows, environt variable names are case-insensitive, but the base library "rio" used by stack doesn't ignore case when looking up environment variables. Under certain circumstances, the program path environment variable is called Path, not PATH. This is the case on the system the issue was observed on:
C:\Users\Michael\source\repos\dummy>set | findstr /i path
HOMEPATH=\Users\Michael
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;...;C:\ghcup\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PSModulePath=C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
In this case, stack fails to expand the PATH variable, so the correct extra-path entries in config.yaml are ignored.
To fix the problem, use the windows environment variables dialog to adjust the spelling of the systemwide path variable. The spelling of the per-user path variable doesn't matter, as the system path is applied first, and merging the user path entries into that variable keeps the spelling set up by applying the system path.

Using GetObject with file argument produces Error 432: File name or class name not found during Automation

I have a screen scrapping application which is in VB6, It is running on windows server 2003 and now we wanted to upgrade to windows server 2012 64 bit.
I have a problem running the below code, it gives:
Error 432: File name or class name not found during Automation
operation
(ref)
GetObject("E:\Robots\Sessions\session1.edp")
I also tried specifying the class name
GetObject("E:\Robots\Sessions\session1.edp","Extra.system")
Also tried CreateObject first and then GetObject, none of them seems to be working.
Thanks,
Remya

How to install tnsping?

How do I have to install tnsping?
I tried to install oracle-instantclient12.1-basic-12.1.0.2.0-1.x86_64.rpm and I'm able to use some client commands but nog tnsping.
Oracle Instance Client does not include tsnping application. You must run "Oracle Universal Installer" and enable the option for it.
I don't' remember exactly which option you have to set, either it was "Oracle Database Utilities" or "Oracle Net"
Also see McTnsping [link broken] "a Windows stand-alone program which requires no Oracle client". It's portable and doesn't need to be installed.
Usage 1: McTnsping.exe { <tns entry> | <host>:<port> } [<count>]
<tns entry> the net service name in the tnsnames.ora file.
<host>:<port> server name or IP and port (mandatory)
<count> number of times to check target, default is 1.
If whoever will reach the place like me... This is what worked for me:
Instant client Version 12.2.0.1 + sqlplus + tnsping (copied from another server of the same version)
Directory structure and env (as in bash profile):
export ORACLE_BASE=/opt/oracle
export ORACLE_HOME=${ORACLE_BASE}/instant_client122
export PATH=$ORACLE_HOME:$PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME #since all binaries are in $ORACLE_HOME - no bin or lib are present
export TNS_ADMIN=$ORACLE_HOME/network/admin
copy from another server to target:
'tnsping' to $ORACLE_HOME
'$ORACLE_HOME/network/mesg/tnsus.msb' to $ORACLE_HOME/network/mesg
Then put proper values to $TNS_ADMIN/tnsnames.ora and load env variables. After this it should be able to perform 'tnsping' and show proper message as a response.
Here's what I did to copy tnsping over to another machine. In my case, the oracle client is installed at C:\Oracle\product\12.1.0\client_1.
This assumes there's already an Instant Client or similar installed on the destination machine; and that the oracle path and registry keys are set.
(1) Copy tnsping.exe from the source to the destination machine, into client_1\bin.
(2) Copy the following files from client_1\bin to client_1\bin:
oraasmclnt12.dll
oracell12.dll
oraclient12.dll
oraclsce12.dll
oracommon12.dll
oracore12.dll
orageneric12.dll
orahasgen12.dll
oraldapclnt12.dll
oran12.dll
orancds12.dll
orancrypt12.dll
oranhost12.dll
oranl12.dll
oranldap12.dll
oranls12.dll
oranro12.dll
orantcp12.dll
orantns12.dll
oraocr12.dll
oraocrb12.dll
oraocrutl12.dll
oraplp12.dll
orapls12.dll
ORASLAX12.DLL
orasnls12.dll
oraunls12.dll
orauts.dll
oravsn12.dll
oraxml12.dll
orazt12.dll
oraztkg12.dll
This should be about 84.6 MB.
(3) In the client_1 on the destination machine, make a backup of the following files:
oci.dll
orannzsbb12.dll
oraons.dll
orasql12.dll
orawsec12.dll
Now on the source machine, find those files in client_1\bin and copy them to client_1\ (no bin) on the destination machine, overwriting the existing files. (Note: oci.dll is ~330 kb smaller, orasql12.dll is ~300 kb smaller. I'm not sure what's lost, hence the backup).
(4) On the destination machine, create the directory mesg in client_1\Network. Now copy the following file from the source to the destination:
client_1\Network\mesg\tnsus.msb
(5) Open up regedit. Create the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\KEY_OraClient12Home1_32bit
(From another machine, it looks like the x64 version is named HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\KEY_OraClient12Home1, but the tnsping program I'm using says it's 64 bit, so ...)
Under the key, create a string named ORACLE_HOME with the value C:\Oracle\product\12.1.0\client_1.
You should be done now ($$$ = redacted):
C:\Users\$$$>tnsping $$$
TNS Ping Utility for 64-bit Windows: Version 12.1.0.2.0 - Production on 03-APR-2
019 08:47:37
Copyright (c) 1997, 2014, Oracle. All rights reserved.
Used parameter files:
C:\Oracle\product\12.1.0\client_1\network\admin\sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = $$$)(PORT = $$$))) (CONNECT_DATA = (SERVICE_NAME = $$$
$$$) (SERVER = DEDICATED)))
OK (30 msec)
Troubleshooting
Here's the process I followed, sharing for when these steps invariably fail to work on a later version.
First off, I just copied the tnsping.exe over.
I didn't haphazardly pick the above dlls, as far as I can tell everyone is required. I ran the exe, and it would popup an error, I would copy the dll over and try again:
After a few dlls, you'll run into a different kind of error:
If that happens, fire up process monitor and put a filter in for the ProcessName to contain tnsping and try to run the program again. You should see something like the following. The main thing to notice is that it tries to load (in this example) orawsec12.dll, which succeeds, but then it continues to try to load the dll looking in different paths, and then at the end it triggers werfault and the program ends. I guess it realizes there's some kind of version mismatch and keeps looking for the right version.
The missing registry key will show up like the following in process monitor (operation RegOpenKey, result NAME NOT FOUND):
If the tnsus.msb file is missing, you should see something like the following in process monitor (operation CreateFile, result NAME NOT FOUND):

Automap library issue in Windows7 (with R 3.0.1)

I installed sp and automap libraries to my R 3.0.1 64-bit under Windows 7 (via install.packages command). Installation of them did not display any error and library(sp) works fine however when I try to execute library(automap) I get the following error:
> library(automap)
Error in gzfile(file, "rb") : cannot open the connection
In addition: Warning messages:
1: In read.dcf(file.path(p, "DESCRIPTION"), c("Package", "Version")) :
cannot open compressed file 'C:/Program Files/R/R-3.0.1/library/sp/DESCRIPTION', probable reason 'No such file or directory'
2: In gzfile(file, "rb") :
cannot open compressed file '', probable reason 'Invalid argument'
I looked from the path and indeed there is no DESCRIPTION file (or folder) in that path. However there is just libs folder under which folder x64 and inside it file sp.dll
Any idea what could cause this?
I would definitely try to run R as administrator, both for installing the packages and loading them. This could solve your problem.
This probably has to do with file permissions. When you install the packages as admin in a location where only admin can read/write, running R as a normal user means you do not have the file permissions needed to load the package. Running R as admin will solve this, as admin does have the correct permissions.
Alternatively, you could install your R packages in a location where a normal user has read/write persmissions, e.g. C:/Users/UserName (or something like that, I do not have my windows machine accesible right now).

Resources