While running a script to create an NSIS installer, I'm getting an error I can't figure out. The script copies the files needed to create the installer, and then calls makensis to build the setup.exe.
During the compilation with makensis, I get an error while trying to include a directory structure that was copied before makensis was called.
The error is: File: failed opening file "..\..\..\My\Long\Path\Name\To\File.ext"
It fails reliably on a specific file that is 5 directories deep from the File /r command used to include the directory structure. The total path length is 180 characters, so it is not insanely long.
This error persists even after reboots or deleting and recreating the entire directory structure. To make it even worse, it works fine on another machine.
I've used Process Monitor to watch the usage of the files in the directory, and there isn't anything that is opening the file after the copy completes.
Any idea how to solve this problem?
The complete path (Current directory + relative path) has to be < 260 characters.
Are you sure your Process Monitor filters are correct, there should be some type of action taken that then fails? The "File: failed opening file" message is printed if CreateFile fails...
I was getting the same error and the complete path was < 260 characters.
Problem
File: failed opening file "\FOLDERSHARE\XYZSRelease\XYZV1.2.2\AutoCompleteMenu.dll"
Error in script "C:\TFS\XYZProject\Releases\NullsoftInstaller\XYZWin7Installer.nsi" on line 77 -- aborting creation process
Cause
For some reason when the files are on a Folder Share it doesn't work (I am positive this is a change to the corporate network environment) as it previously was working.
Solution
Put all the files in C:\Temp or another local directory.
Related
I am using the command: dotnet "myfile.dll"
Initially it was giving me this error: The user's home directory could not be determined. Set the 'DOTNET_CLI_HOME' environment variable to specify the directory to use.
Now after messing around with it, I have moved my files to c:/mydir, and it is giving this error: Failed to initialize CoreCLR, HRESULT: 0x80070057. I found this, but isn't c:/mydir a drive root?
Couple of things I noted:
I am able to run the .dll fine in a different directory.
Both directories contain same files.
The reason I want to run it in c:/mydir is because I am using AWS CodeDeploy, and that is where it copies the files (as far as I know; and the other directories are just the old versions where the files get copied from).
These issues are not linked (the first one I get from running a automated shell script after installation, and the second I get from manually trying to launch the .dll).
If someone could help me solve either one of these issues it would be greatly appreciated.
Try adding Environment=DOTNET_CLI_HOME=/temp to your Service declaration in your .service file. Example syntax:
[Service]
...
Environment=VARNAME=VARCONTENTS
So the actual like would look like this
Environment=DOTNET_CLI_HOME=/temp
I am in the process of making a discord bot. All of the code that I have written for the bot works except for the batch file that is supposed to run it. Originally I was just using the node command and when I opened cmd, navigated to the folder, and typed it manually it worked fine, but when I put that same code into a batch file it gave me this error:
'node' is not recognized as an internal or external command, operable program or batch file.
This is all the code for that batch file:
#echo off
node bot.js
pause
The node command was in my path so I'm not sure why it wasn't working, but in another post, someone recommended that instead of typing just node to type the full file path, so I tried this and it worked.
Here is the new working code:
#echo off
"C:\Program Files\nodejs\node.exe" bot.js
pause
Then I installed nodemon. Again this works in the cmd when I navigated to the folder and typed it manually, but when I try to do it in the batch file it does not work. Instead of giving me the error it had been before the window just instantly closes. Here is that code:
#echo off
nodemon bot.js
pause
Since I have the pause command at the end of the code it should stop there if I get an error, but it is closing before it gets there for some reason. The nodemon command is in my path and I have also tried replacing nodemon with the file path, C:\Users\tdkni\AppData\Roaming\npm\nodemon.cmd, like I was recommended in the previous post. Neither of these solutions worked, and I think that is because there is some other problem besides the nodemon command not being detected. I don't see any error message since it is closing instantly so I don't know exactly what is wrong.
The registration of the file extensions .bat and .cmd is as follows according to an advice in a comment deleted in the meantime.
Well, it is pretty clear why node.exe was not found by cmd.exe in directory C:\Program Files\nodejs.
Local Path being system and user Path concatenated contains "C:\Program Files\nodejs;" instead of just C:\Program Files\nodejs.
Folder paths in Path should be never enclosed in double quotes with one exception: The folder path itself contains one or more ;. In this case the folder path with ; must be enclosed in double quotes to get the semicolon(s) in folder path not interpreted as separator between the folder paths. That is general CSV syntax as described on Wikipedia article comma-separated values which is used by Windows for the folder paths in Path with using semicolon as separator.
For that reason cmd.exe searches in a folder with name C:\Program Files\nodejs; for node.* with a file extension listed semicolon separated in environment variable PATHEXT. But there is no folder C:\Program Files\nodejs; because the folder is C:\Program Files\nodejs without the semicolon at end.
And also PATHEXT is defined wrong as it contains at end the folder path C:\Program Files\nodejs although it should contain only file extensions separated by a semicolon.
Other small mistakes:
The first 4 folder paths in system PATH should be always:
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SystemRoot%\System32\WindowsPowerShell\v1.0
Some installers add folder paths at beginning of folder paths list instead of appending them at end as it can be seen here. The Intel64 compiler and the Oracle Java folder paths should be moved in system PATH after PowerShell folder path.
Folder paths can but should not end with a backslash. All backslashes at end of a folder path should be removed from system and user PATH. Microsoft added since Windows Vista the PowerShell path with a trailing backslash for some unknown reason. But it is safe and recommended to nevertheless remove the backslash after WindowsPowerShell\v1.0.
System and user Path (if latter is existing at all) and also PATHEXT should not end with a semicolon. There should be no ; after last folder path respectively last file extension as this means according to CSV specification that there is one more value (folder path, file extension) which is an empty value.
I recommend to define system Path with following value respectively folder paths:
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SystemRoot%\System32\WindowsPowerShell\v1.0;%SystemRoot%\System32\OpenSSH;%ProgramFiles(x86)%\Common Files\Intel\Shared Libraries\redist\intel64\compiler;%ProgramFiles(x86)%\Common Files\Oracle\Java\javapath;%ProgramFiles%\nodejs;%ProgramFiles(x86)%\Windows Kits\8.1\Windows Performance Toolkit
I recommend to define user Path with following value respectively folder paths:
%LocalAppData%\Microsoft\WindowsApps;%AppData%\npm
Those two folder paths are user account related and should be added for that reason to user and not system Path.
I recommend to fix system environment variable PATHEXT to:
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
For more details about usage of Path and PATHEXT see the answer on What is the reason for '...' is not recognized as an internal or external command, operable program or batch file? Please take also a look on Wikipedia article about Windows Environment Variables.
Here's my answer to the original question, for the benefit of other Windows users (Linux/Mac users not my problem).
In essence, user is trying to run some script.js file with nodemon;
C:\path\to\my\project>nodemon bot.js
, and wants to put in a batch file.
If nodemon is installed globally -g, it installs under
C:\Users\<YourLogin>\AppData\Roaming\npm\nodemon.cmd
So your batch file should be
cd C:\path\to\my\project\
%AppData%\npm\nodemon.cmd bot.js
PAUSE press any key to exit
I'd like to thank all of you for trying to help me with this problem I was having. You have all been very helpful, and while it may not have fixed my problem it did help me understand how all of this works. I just tried to start the bot using the batch file I made and it suddenly worked. I don't know why because I tried to start it the same way I had been the entire time, but as far as I could find, no one else was having this issue anyways so it probably won't matter much that I don't know what fixed it. Again, thank you to everyone that helped me with this.
Give this a try for us please, if it works, I will explain:
#echo off
cd /d "C:\Users\tdkni\AppData\Roaming\npm"
echo Testing Script > OUTPUT.log
nodemon.cmd bot.js >> OUTPUT.log
pause
I know this thread is older but I faced the same issue today. If someone like me stumbled across, based on joedotnot's answer, here is what it fixed for me.
devserver.cmd
#echo off
echo Auto Starting Development Server
cmd /k "cd x:\cmdproxy & config\env.cmd & %AppData%\npm\nodemon.cmd"
Where X: is the development folder on the VM Host System mapped as Network Drive in the development Guest System. And config\env.cmd is another batch file which holds some env settings.
My server file is named index.js so there was no need to add is as argument. Nodemon finds the file automatically.
I'm experiencing a weird problem, I have a header file that is included in source files (c++),now whenever I run 'make' on any source file I get the error:
pin.H: No such file or directory
pin.H is found in a different directory (but in some parent directory of the source files), anyway this shouldn't make a problem in my case, the files (sources, headers, makefile, libraries and even exe. files) are given to us by course staff and it's meant to work this way.
I was able to compile successfully before, but somehow after several attempts to run a test on some source file, I had probably made something wrong, I used 'chmod' on some files (and directories maybe), because while trying to run a test I was getting : "Permission denied", However I doubt that I've made chmod for something that it now can't reach that header file anymore (while compiling).
And if that is the case, can I somehow restore "the initial mode" of the system?
I am trying to run the make command, but it says
/bin/sh: line 0: cd: /h1/cs/Desktop/cmake/ME/build: No such file or directory
make: *** [cmake_check_build_system] Error 1
This is possibly caused because I used to keep my files in that directory, but I deleted that directory and I moved the source files, CMakeLists.txt, etc, basically everything, from the old to new directory. The new directory is ws/cs/cmake/ME. Yes, I tried to run make in that new directory, and the error above is what I got. Because the new directory has a massive number of sub-directories, I'm not sure which file I need to change so that it knows about the new directory Where in my new directory do I need to change the path, so I can then run make again?
If you delete and start compiling from a new directory you will get an easy fix.. For other options try searching with combination of file and grep.
Believe this is a CLion question.
I'm late to the party but, if someone's looking then -
delete the cmake-build-debug folder entirely from within the project.
select the folder saying your <PROJECT_NAME>, under which the cmake-build-debug folder was present originally, then right click and Reload CMake Project
InnoSetup appears to be corrupting my executable when compiling the setup project.
Executing the source file works fine, but executing the file after installation produces Win32 error 1006 "The volume for a file has been externally altered".
I've tried disabling compression and setting various flags, to no avail.
Has anyone experienced this?
UPDATE
Okay there's been some twists to the situation:
At the moment, I can even manually copy a working file to the location it is installed to and get "The volume for a file...". To be clear: I uninstall the application, create the same folder and paste the files there and run.
UPDATE 2
Some more details for those that want it:
The InnoSetup script is compiled by FinalBuilder using output from msbuild, also executed by FinalBuilder, running on my machine with XP SP3. The executable is a C# .Net assembly compiled in configuration Release|AnyCPU. The file works when executed in the folder the Install Script takes it from. It produces the same behaviour on an XP Virtual Machine. The MD5 hashes of the source file and the installed file are the same.
Ok, I just received this same error. I have a config which my executable uses. I looked in my folder a million times - but finally notice the config file was zero length. I corrected the config and the error stopped occurring.
Check the simplest things first... good lucK!
ERROR_FILE_INVALID
1006 (0x3EE): The volume for a file has been externally altered so that the opened file is no longer valid.
I suspect you're having this issue after moving the files to a network share. It seems to me that what's happening is you have an open file-handle - possibly to a temporary file you are creating - and then some other process (perhaps running on a different host) is coming along and renaming or deleting that file or its' parent directory tree.
So my advice is:
Try installing to a local directory
Run after an anti-virus scan, in
safe-mode or on a different machine
to see if there isn't some
background nasty changing
volume/directory properties while
your program is running.
Make sure the program itself isn't doing anything weird with the volume or directory tree you're working with.
Never seen that before. I've got a few questions and suggestions:
- Are you signing the EXE during the compile of the setup? If so, try leaving that part out.
- WHat OS are you installing on or does it happen on all machines you've tried?
- Run the install with the /LOG="c:\install.log" option and post the log. It might show something happening during install.
- Run a byte compare or MD5 check on the source EXE and the installed EXE. Are they the same? Do they have the same version resource?