Visual Studio 2008 References too long? - visual-studio

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.

Related

Unable to load/require file from Lua running from Atom in Windows

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.

Where is the use of "\\?\" defined?

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?

Windows directory that will never contain non-ASCII characters for temp file?

Using MinGW 7.3.0 on Windows, Hunspell can't load the dictionary files from locations that have non-ASCII characters because of Windows limitations. I've tried everything[1] and I'm now resorting to copying the file to a path without ASCII characters before giving it to Hunspell. What is a good location to copy it to?
[1]
Windows requires wchar_t support for std::iostream.open() to work right, which MinGW does not implement
std::filesystem can solve this, but only available in GCC 8
Hunspell insists on loading files on its own, it is not possible to pass the read files as strings to it
The "natural" fit would be the use the user's choosen temporary directory (or subdirectory thereof) (see %temp% or GetTempPath()). However, that defaults to something that contains the user name (which can contain "non-ASCII" characters; e.g. c:\users\Ø¥Ć¼\AppData\LocalLow\Temp) or something arbitrary (regarding character set) all together.
So you're most likely best off to choose some directory that
a) does not contain off-limits characters from the get go. For example, a directory underneath C:\ProgramData that you choose yourself (e.g. the application name) that you know does not contain non-ASCII characters.
b) let the user decide where to put these files and make sure it is not permissible to enter a path that contains only allowed characters.
c) Pass the "short path name" to Hunspell, which should not contain non-ASCII characters for compatibility with FAT file system traits. For example, the short path name for c:\temp\Ø¥Ć¼ is c:\temp\571D~1.
You can see the short names for directories using cmd.exe /c dir /x:
C:\temp>dir /x
...
19.07.2019 15:30 <DIR> .
19.07.2019 15:30 <DIR> ..
19.07.2019 15:30 <DIR> 571D~1 Ø¥Ć¼
How you can invoke the GetShortPathName Win32 API from MinGW I don't know, but I would assume that it is possible.
Also make sure to review the MSDN page for the above function for traitoffs, e.g. short names are not supported everywhere (e.g. SMB + see comments below).
From this bug tracker:
In WIN32 environment, use UTF-8 encoded paths started with the long
path prefix \\?\ to handle system-independent character encoding
and very long path names (without the long path prefix Hunspell will
use fopen() with system-dependent character encoding instead of
_wfopen()).
So the actual solution seems to be:
Call GetFullPathNameW to normalize the path. Required because paths with long path prefix \\?\ are passed to the NT API unchanged.
Prepend L"\\\\?\\" to the normalized path (backslashes doubled because of C string literal requirements).
For a UNC path, you have to use the "UNC" device directly (i. e. L"\\\\server\\share" → L"\\\\?\\UNC\\server\\share" (thanks eryksun)
Encode the path in UTF-8, e. g. using WideCharToMultiByte() with CP_UTF8.
Pass the final UTF-8 encoded path to Hunspell.
It looks like C:\Windows\Temp is still a valid path you can write to yourself.

Increase Allowable File Path Length

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

MSDOS - "The system could not find the file specified"

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

Resources