Is it possible to increase the file path/string length for NSIS? I am attempting to use the function FILE with a path that is rather long and I get the compile error:
File: failed opening file "..\..\..\..\12d\10.00\DPTI_Customisation\\DESIGN_12d10\DPTI_Design_User\DPTI_D_Toolbars\DPTI_D_Create_D_Boundaries_for_Tin.slx"
Is it possible to increase the allowable length like how you can increase the $NSIS_MAX_STRLEN varaible length?
This thread says that the error is caused by the file path being too long.
Edit
Heres the code:
FILE /r "..\..\..\..\12d\10.00\DPTI_Customisation\"
# The folder DPTI_Customisation contains many sub folders and files
You could try using the unicode version of NSIS.
Alternatively, I wonder if you could use multiple calls to cd in order to reduce your path length.
Ref: http://nsis.sourceforge.net/Docs/Chapter5.html#5.1.5
Related
I'm trying to use Atom to run a Lua script. However, when I try to load files via the require() command, it always says it's unable to locate them. The files are all in the same folder. For example, to load utils.lua I have tried
require 'utils'
require 'utils.lua'
require 'D:\Users\Mike\Dropbox\Lua Modeling\utils.lua'
require 'D:\\Users\\Mike\\Dropbox\\Lua Modeling\\utils.lua'
require 'D:/Users/Mike/Dropbox/Lua Modeling/utils.lua'
I get errors like
Lua: D:\Users\Mike\Dropbox\Lua Modeling\main.lua:12: module 'D:\Users\Mike\Dropbox\Lua Modeling\utils.lua' not found:
no field package.preload['D:\Users\Mike\Dropbox\Lua Modeling\utils.lua']
no file '.\D:\Users\Mike\Dropbox\Lua Modeling\utils\lua.lua'
no file 'D:\Program Files (x86)\Lua\5.1\lua\D:\Users\Mike\Dropbox\Lua Modeling\utils\lua.lua'
no file 'D:\Program Files (x86)\Lua\5.1\lua\D:\Users\Mike\Dropbox\Lua Modeling\utils\lua\init.lua'
no file 'D:\Program Files (x86)\Lua\5.1\D:\Users\Mike\Dropbox\Lua Modeling\utils\lua.lua'
The messages says on the first line that 'D:\Users\Mike\Dropbox\Lua Modeling\utils.lua' was not found, even though that is the full path of the file. What am I doing wrong?
Thanks.
The short answer
You should be able to load utils.lua by using the following code:
require("utils")
And by starting your program from the directory that utils.lua is in:
cd "D:\Users\Mike\Dropbox\Lua Modeling"
lua main.lua
The long answer
To understand what is going wrong here, it is helpful to know a little bit about how require works. The first thing that require does is to search for the module in the module path. From Programming in Lua chapter 8.1:
The path used by require is a little different from typical paths. Most programs use paths as a list of directories wherein to search for a given file. However, ANSI C (the abstract platform where Lua runs) does not have the concept of directories. Therefore, the path used by require is a list of patterns, each of them specifying an alternative way to transform a virtual file name (the argument to require) into a real file name. More specifically, each component in the path is a file name containing optional interrogation marks. For each component, require replaces each ? by the virtual file name and checks whether there is a file with that name; if not, it goes to the next component. The components in a path are separated by semicolons (a character seldom used for file names in most operating systems). For instance, if the path is
?;?.lua;c:\windows\?;/usr/local/lua/?/?.lua
then the call require"lili" will try to open the following files:
lili
lili.lua
c:\windows\lili
/usr/local/lua/lili/lili.lua
Judging from your error message, your Lua path seems to be the following:
.\?.lua;D:\Program Files (x86)\Lua\5.1\lua\?.lua;D:\Program Files (x86)\Lua\5.1\lua\?\init.lua;D:\Program Files (x86)\Lua\5.1\?.lua
To make that easier to read, here are each the patterns separated by line breaks:
.\?.lua
D:\Program Files (x86)\Lua\5.1\lua\?.lua
D:\Program Files (x86)\Lua\5.1\lua\?\init.lua
D:\Program Files (x86)\Lua\5.1\?.lua
From this list you can see that when calling require
Lua fills in the .lua extension for you
Lua fills in the rest of the file path for you
In other words, you should just specify the module name, like this:
require("utils")
Now, Lua also needs to know where the utils.lua file is. The easiest way is to run your program from the D:\Users\Mike\Dropbox\Lua Modeling folder. This means that when you run require("utils"), Lua will expand the first pattern .\?.lua into .\utils.lua, and when it checks that path it will find the utils.lua file in the current directory.
In other words, running your program like this should work:
cd "D:\Users\Mike\Dropbox\Lua Modeling"
lua main.lua
An alternative
If you can't (or don't want to) change your working directory to run the program, you can use the LUA_PATH environment variable to add new patterns to the path that require uses to search for modules.
set LUA_PATH=D:\Users\Mike\Dropbox\Lua Modeling\?.lua;%LUA_PATH%;
lua "D:\Users\Mike\Dropbox\Lua Modeling\main.lua"
There is a slight trick to this. If the LUA_PATH environment variable already exists, then this will add your project's folder to the start of it. If LUA_PATH doesn't exist, this will add ;; to the end, which Lua fills in with the default path.
This command is to delete all files and sub-folders in a folder
rd /s "\\?\D:\TestFolder
This command snippet got from a youtube video right here
Could someone explain what this, \\?\, does?
It's the prefix to bypass Windows path normalization. With it you'll be able to access paths that are not valid in Win32 namespace like names ending with . or spaces: D:\TestFolder\folder ending with space \file name ending with dot., or files with path longer than MAX_PATH (260 characters in older Windows)
For file I/O, the "\\?\" prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system. For example, if the file system supports large paths and file names, you can exceed the MAX_PATH limits that are otherwise enforced by the Windows APIs. For more information about the normal maximum path limitation, see the previous section Maximum Path Length Limitation.
Naming Files, Paths, and Namespaces - Win32 File Namespaces
See
Dots at the end of file name?
How to copy files that have too long of a filepath in Windows?
I am trying to copy the contents of a log file to another log file using this command:
type \\server\f$\Test path\Test.log >> \\server2\f$\Logs\Testpath\Test.log
This has always worked in the path, but recently I have changed the location (path) to Test.log. The path is slightly longer. I now get an error:
The system could not find the file specified
I have googled this statement and the common responses are: 1) check the filename exists, 2) check the filename is not corrupt 3) Check the server is online.
I have done all of this. Is there a restriction on the number of characters a path can have? If there is then is there a workaround?
UPDATE 12/07/2012 09:49 GMT
Adding quotes around the path seems to resolve the problem. Why does adding quotes resolve the problem?
The problem was that the source path had a space in it. Adding quotes around the path resolved the problem.
Type is to examine a file, not to copy.
Also, if server is an actual server and not a folder, then you should be using two slashes (\server\share)
Example:
copy \\server\f$\Sourcepath\Test.log \\server2\f$\Logs\Destpath\Test.log /y
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds.mspx?mfr=true
On a Linux system I have a binary (bin.exe) which needs to read an input file (input.cfg), where the names of other data files (data.txt) are specified. Usually both binary, input file and data files were in the same directory. Now and for organization reasons I need binary file to be in $SOMEPATH/bin and input and data files in $SOMEPATH/input.
I do not know how to do this. If I try
$SOMEPATH/bin/bin.exe $SOMEPATH/input/input.cfg
I get
error, "data.txt" not found
One solution would be to include absolute of relative path of "data.txt" in input.cfg, but the binary does not accept this.
I thought about somehow fooling the binary so that it thinks it is in $SOMEPATH/input, so that I just do
$SOMEPATH/bin/bin.exe input.cfg
and it works, but I do not know whether this is possible. any hints?
(cd $SOMEPATH/input && $SOMEPATH/bin/bin.exe input.cfg)
This is assuming that the program is relying on the current working directory to find the files. If the program is trying hard to find them in the same location as the executable, by consulting /proc/<pid>/exe for example, then you may be out of luck.
I have recently re-organised our source control and found one of our solutions no longer builds. The only error that we get is:
Error 65 Unknown build error, 'The
specified path, file name, or both are
too long. The fully qualified file
name must be less than 260 characters,
and the directory name must be less
than 248 characters.'
I went through each reference in visual studio and the longest complete path (path AND filename) of each reference was 161 characters.
My solution folder structure is thus:
C:\projects_svn\ABC\branches\01.02.03\ABC\ABC
SUITE\ABC.DEF.GHIJKLM.NOP\
Any help would be greatly appreciated, I do not feel this folder structure is too long, given the project size, and organises things much better.
Here are some technical details which may help (if you need more let me know):
Visual Studio 2008 SP 2 running on Windows XP or Windows 7. Using Subversion as SCM. Coding in C#/WPF.
Thanks
I think what's likely happening here is that one of your projects is using a relative hint path that is going very far back up the tree and then back down the directory structure. For example
c:\foo\bar\baz\..\..\..\some\other\dir\foo.dll
Even though the path to the actual file is less than 256 the relative goop makes it much longer.
The best way to find these is to search all of your .csproj / .vbproj files for the string ..\..\. See if that turns up any results.
You also need to consider the "backdrop" files for SVN.
While I might have a short file name like this:
c:\myfolder1\myfolder2\MyFile.txt
There is probably lurking somewhere a longer file name version like this:
c:\myfolder1\myfolder2.svn\text-base\MyFile.txt.svn-base
And that backdrop file is the one that gets the "way too long" error.
Here is what I get via CCNET (calling a MSBUILD file) using SVN source control.
Specific names removed to protect the innocent. (And my job!)
Please note that this "name massaging" results in shorter paths that probably would not generate the errors. Aka, don't count the number of characters in my massaged examples.
But the error messages are what I was getting.
Removing directory "C:\CCNETEnvironment\MyFolder2\MyProject\working\checkout".
C:\src\MyFolder1\MyProject\My_MSBuild.xml(173,5): error MSB3231: Unable to remove directory "prop-base". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
C:\src\MyFolder1\MyProject\My_MSBuild.xml(173,5): error MSB3231: Unable to remove directory "text-base". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
C:\src\MyFolder1\MyProject\My_MSBuild.xml(173,5): error MSB3231: Unable to remove directory "prop-base". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
C:\src\MyFolder1\MyProject\My_MSBuild.xml(173,5): error MSB3231: Unable to remove directory "text-base". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
C:\src\MyFolder1\MyProject\My_MSBuild.xml(173,5): error MSB3231: Unable to remove directory "C:\CCNETEnvironment\MyFolder2\MyProject\working\checkout". Could not find a part of the path 'MyFile.txt.svn-base'.
Done building target "Clean" in project "My_MSBuild.xml" -- FAILED.