So I have an windows msi installer that I created by cross compiling from a golang program and installed on a client windows machine. The program sends data out from a folder on the windows machine to a Kinesis stream. The program works fine for all files and folders on the local C:\ drive.
My issue is that when the client is using a mounted NTFS drive ("I://, J://, D://") I get an error message with
level=info msg="Ignoring target I:\\xml with invalid stat: open I:\\xml: The system cannot find the path specified."
No matter the mounted drive (E,F,G, etc) I get the same error message.
I've tried this across multiple clients and received the same error.
So just for background- I'm compiling the program using wine to get it to an msi when building. The program is taking on a SYSTEM USER role and I've already checked permissions on the mounted directories (and made them wide open- still no luck). Been banging my head against the wall over this one for a while so the question is: has anyone else had an issue like this?
Don't know how much this will help but here is the specific portion of GO code I'm using:
p, err := filepath.Abs(t.Path)
if err != nil {
Logger.Infof("Ignoring invalid target path: %s, error: %s", t.Path, err)
continue
}
_, err = os.Lstat(t.Path)
if err != nil {
Logger.Infof("Ignoring target %s with invalid stat: %s", t.Path, err)
continue
}
c.targets = append(c.targets, site.WatchTarget{p, t.SrcTag})
I've tried os.Stat, Lstat and even os.Open to no avail. Just about at the end of my tether on this one.
The ideal result would be a suggestion on any changes you could suggest that would allow a system user from a cross compiled go program to see mounted network drives.
Related
I am running a Go application in a Debian environment. All my development has been carried out on OSX and it ran fine, but I am having a problem running a command on shell from my Go code.
cmdName := "cwebp"
cmdArgs := []string{srcPath, "-o", dstPath}
log.Printf("Executing %s : %+v", cmdName, cmdArgs)
cmd := exec.Command(cmdName, cmdArgs...)
_, err := cmd.StdoutPipe()
if err != nil {
log.Printf("Error: %s", err)
}
err = cmd.Run()
if err != nil {
log.Printf("Error: %s", err)
}
The application process is running from my root user and the command works fine when I run it from shell.
Earlier, I thought that I am facing the issue due to an incorrect PATH environment variable. On printing that before running the command, I get the correct path. Moreover, I have tried to use LookPath and got the correct path as /usr/local/bin/cwebp.
The problem was not with the execution of the command but somehow Go was not able to find the correct library. On checking the output of the command, I got the following:
cwebp: error while loading shared libraries: libwebp.so.5: cannot open shared object file: No such file or directory
This led me to the direction that the installation of libwebp must have been faulty. Earlier, I had built libwebp from source. So, I installed it via apt-get install libwebp-dev and the command ran successfully.
I'm running Qt 5.3.1 on Mac OS X 10.8 and 10.9 I'm trying to use the macdeployqt tool to bundle libraries and plugins with my executable, but it's apparently trying to include everything on my hard drive.
I invoke it with:
/Applications/Qt/5.3.1/5.3/clang_64/bin/macdeployqt /Users/adamwilt/Desktop/temp/DesktopPixie.app -verbose=2
-qmldir=/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/DesktopPixie
and get lots of normal, expected log messages like:
Log: copy: "/Applications/Qt/5.3.1/5.3/clang_64/qml/QtQuick/Controls/Styles/Base/images" "/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/QtQuick/Controls/Styles/Base/images"
...and all runs fine until I start getting messages like:
Log: copy: "" "/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/MessageBoxUI/Enums"
ERROR: file copy failed from "/do-gst"
ERROR: to "/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/MessageBoxUI/Enums/do-gst"
ERROR: file copy failed from "/rescuepro.properties"
ERROR: to "/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/MessageBoxUI/Enums/rescuepro.properties"
ERROR: file copy failed from "/rescuepro34act.lic"
and then the fun begins:
Log: copy: "/Applications" "/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/MessageBoxUI/Enums/Applications"
Log: copied: "/Applications/License.rtf"
Log: to "/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/MessageBoxUI/Enums/Applications/License.rtf"
Log: copy: "/Applications/0xED-1.0.7.app" "/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/MessageBoxUI/Enums/Applications/0xED-1.0.7.app"
It appears it's trying to copy everything (that is, "") into the app, but I ^C out of it while I still have disk space left!
It didn't do this at first; then it did so for a week; then it stopped; now it's back. This is a distributed development project; I'm doing the QML stuff and folks elsewhere are doing the C++. It's possible the other folks are changing a configuration somewhere that's causing this to occur, but I'm the only one doing Mac deployments, so I'm the only one who sees this.
Is there a config file of some sort for macdeployqt where this might be getting triggered? Or is it more likely a problem related to the C++ object MessageBoxUI, which defines several Q_ENUMs (apparently correctly, as it compiles without warnings or errors, and appears to run properly), since that's the target directory when it starts going mad?
Sussed it (well enough that I can go on):
The Qt app I'm trying to deploy lives in ~/Desktop/temp. If I set my current directory to ~/Desktop or ~/Desktop/temp before I run macdeployqt, it runs as expected.
If I run it from from my home directory ~, or ~/Documents, macdeployqt tries to pull in everything it finds in /Applications, /opt, and/or other directories unassociated with the app.
Setting cwd to most other paths, including ~/Downloads, /Applications, subdirectories of ~/Documents, etc. also seems to work; it's only running macdeployqt from ~ and ~/Documents that causes the problem.
No proper explanation as to why this is happening, but just a warning in case someone else sees this sort of weird behavior: try changing to the apps's location before running macdeployqt.
git is installed on windows and works from any directory (it is in System path)
var child_process = require('child_process');
child_process.exec('git --version', function(err, stdout, stderr) {
// stdout is correct - git version 1.7.11.msysgit.1
// but err is not null
// err is [Error: Command failed: ] killed: false, code: 1, signal: null }
}
What can cause this?
I had this issue using Windows 7 with msysgit. Two things seem to solve the issue.
First, verify that your Path system variable includes a path to the Git bin directory, and not the cmd directory:
C:\Program Files (x86)\Git\bin
Next, verify you have a recent version of msysgit. I've verified the issue as solved with version 1.8.4-preview:
https://code.google.com/p/msysgit/downloads/list
Restart your shell and try again.
As a workaround you can pass {env:{PATH:"C:\path to\node"}} as the options argument to process.exec(cmd, opts, callback) as described in docs. I am surprised that the Windows path doesn't carry over but have no explanation why.
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).
I am running on a Win2K8R2 system that has Microsoft's NFS client installed in addition to the Windows CIFS client.
Given a UNC path (which the NFS client does support with caveats) I need to be able to tell if operations on the path would be handled by the CIFS or NFS client. WNetGetResourceInformation() would seem to provide this, but I have not been able to get it to work when the UNC path is to an NFS server.
Sample code:
int GetResourceInformation(TCHAR* path, void* buffer, DWORD* size)
{
TCHAR* p = NULL;
NETRESOURCE nr;
memset(&nr, 0, sizeof(nr));
nr.lpRemoteName = path;
DWORD dwRetVal = WNetGetResourceInformation(&nr, buffer, size, &p);
if(dwRetVal == NO_ERROR)
{
NETRESOURCE* tmp = (NETRESOURCE*)buffer;
wprintf(L"%s provider=%s system=%s\n", path, tmp->lpProvider, (p == NULL) ? L"<null>" : p);
}
else
{
wprintf(L"WNetGetResourceInformation failed for %s with error: %u\n", path, dwRetVal);
}
return dwRetVal;
}
I have also tried filling in the NETRESOURCE lpProvider and/or dwType fields as suggested in the doc but with no change in behavior.
If I pass the function a CIFS UNC path it succeeds. If I pass it an NFS UNC path it fails with error 487 "Attempt to access invalid address.". I also tried passing the native NFS path style hostname:/export/file but this fails with error 67 "The network name cannot be found."
I found the following sample for using WNetAddConnection2() with NFS but this code also fails for me with error 50 "The request is not supported". I can successfully mount the export using either "net use" command or the NFS-specific mount.exe tool provided by Microsoft.
Finally, WNetOpenEnum/WNetEnumResource does not return any NFS provider information for me or even show any connected drives that I have mapped via "net use" or mount.exe.
My general question is, has anyone had better success using the the WNet APIs with the NFS provider? Specifically, is there some mechanism I can use to determine the provider for a remote path?
Are you building as x86 or x64? It looks like the WNet* API's don't work correctly for NFS shares from an x86 process under WOW64. You can see this without writing code - if you have an NFS share mounted, "C:\windows\system32\net use" will show it, where "C:\windows\syswow64\net use" will not. Filesystem access seems OK the 32-bit process, but none of the APIs work.
Even built as x64, using a NULL lpProvider is inconsistent for me. Half the time it doesn't work, the other half it waits about 5 seconds before returning.
Calling WNetGetResourceInformation twice, once with a lpProvider of "NFS Network" and once with "Microsoft Windows Network" works consistently and returns instantly.