I'm working in a project that stores files with very long paths.
I need to use network paths such as \\server\share\files.. paths. But I cannot figure out why its not working. I'm running Win7
\\server\share\path\file.exe ( This works but not for very long paths ~266 char long)
This wiki page https://en.wikipedia.org/wiki/Path_%28computing%29 specifies that syntax \\?\UNC\server\share\path\file.exe should work for longer paths but I can't get it to work for either long or short paths.. Not supported for Win7 ?
Anyone has a solution of how i can point to long network paths using a \\xxx syntax with length ~266 characters?
Thanks to Harry Johnston, as a summary to how I solved my problem:
Windows Explorer does not support then \\?\UNC\.. syntax.
Using \\?\UNC\server\folder\.. together with Python 3.4 and shutil.copy2() works perfectly fine. (Which I assume uses the mentioned Unicode API from comments above)
when presenting the user with a directory path i remove ?\UNC\ and leave them with a simple \\server\path\.. path.. (which they, if they want to, copy paste into windows explorer and open the directory.
Related
As suggested by https://www.visualstudio.com/en-us/docs/tfvc/share-your-code-in-tfvc-xcode I am putting my existing code to TFVC using git-tf. But my paths are deep. During check-in I am getting,
git-tf: TF205022: The following path contains more than the allowed 259 characters:
/Users/VeryLongPath
Even though the path length limitation is really annoying, the most effective and easy way still is spending some time tweaking your file/folder structure to make this work.
For example: instead of \xx\Build\Drop\ProjectName, just use \xx\Build\Drop (or \xx\Builds) since the project name is also in the build name.
For the long path issue in TFS, there had been a related uservoice and now completed. However, it's still a problem in some areas.
Fix 260 character file name length limitation
We’ve removed the limitation from the BCL for the basic file
manipulation functionality (CRUD). You can find more details here:
https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/
Immo Landwerth Program Manager .NET
Also suggest you to take a look at this great blog-TFS Path Too Long problems for how to deal with the issue.
In short currently its the TFVC limitation, from https://www.visualstudio.com/en-us/docs/reference/naming-restrictions#version-control-paths
Must not contain more than 259 Unicode characters for a single folder or file name.
I am using ColdFusion 10 on a Windows machine. I am creating a directory for storing generated excel reports using directoryCreate() and spreadsheetWrite() cfscript functions. It works fine on Windows.
I have a work colleague who is developing on a mac with OS X mavericks. When the code is executed on his machine, one of two things happens. Either the file includes the full path name in the actual file name (e.g. "/folder/anotherfolder/thefile.xls" as single file name) and is placed in the root of the web project folder, or a single folder is created with the forward slashes as part of the folder name (e.g. "/folder/anotherfolder/" as single folder name).
Here are a couple of examples that I have tried for creating the initial root folder structure:
request.rootPath = ExpandPath("*.*");
request.rootDirectory = GetDirectoryFromPath(request.rootPath);
OR
request.rootPath = ExpandPath("./");
request.rootDirectory = GetDirectoryFromPath(request.rootPath);
OR
request.rootPath = ExpandPath("/");
request.rootDirectory = GetDirectoryFromPath(request.rootPath);
I then use request.rootDirectory in the directoryCreate() function, e.g.:
// within my fw/1 cfc...
rc.userReportPath = "#request.rootDirectory#folder\anotherfolder\";
if (!directoryExists(rc.userReportPath)) {
directoryCreate(rc.userReportPath);
}
And then create the spreadsheet file (where rc.excelFileName is my dynamic file name based on the logged in user:
spreadsheetWrite(rc.s, "#rc.userReportPath##rc.excelFileName#", true);
The only possible clue I've found so far is something to do with forward slashes being unicode characters that are only being displayed as forward slashes, not actual forward slashes for folder path creation (I hope that makes sense). Although, it may have nothing to do with this. The production environment is on a Windows environment so this isn't a major issue going forward, but being a bit obsessive, I'd really like to know what's really causing this behaviour so that I can avoid it in future.
Thanks in advance to anyone that can help me figure this one out :)
(From comments ...)
What is the actual value of the path ie #rc.userReportPath##rc.excelFileName#? Is it actually valid for OSX? It looks like windows style separators are being used ie \.
Try using / instead, which is valid for both windows and mac.
EDIT: This is due to stupidity. It is a multiple monitor issue. It's just that from cmd.exe we always opened in the primary monitor, whilst from explorer, we always opened in the secondary. Thanks all for the help!
We hit a weird bug recently. We have a Qt + osg app that behaves differently if we run it from explorer than if we run it from a command line. Running from explorer is unusable, while running from command line (or by running from the explorer a simple batch file that calls the .exe) works as expected.
We suspect environment variables, because that's all we can think of. But the fact that it runs fine with a one line batch file seems to refute this. I'm not familiar enough with windows to know of any subtle differences in how it loads executables, nor where to look to find out.
Are there any other differences that could explain this? Does windows load different sets of user environment variables in each case? OS is Windows XP Service Pack 3.
The behavior experienced when running from explorer (double click program.exe) is consistent with a driver issue or improper OSG scene setup: image artifacts, flashing, and weird colors.
The behavior experienced when running the same executable from cmd.exe (or by double clicking a .bat file next to the .exe containing only a line to run the .exe) is the correct, expected behavior: the scene is correct, no flashing, etc.
To rule out potential library load path issues, try using dot-local DLL redirection.
Towards that end, create an (empty) file in the same directory as your executable and give it the same name as your binary, except with .local appended. I.e., if your binary is named yourbinary.exe, name that file yourbinary.exe.local. That will force the PE loader to first look in that directory to resolve LoadLibrary calls (and that includes DLLs loaded indirectly via system DLLs or via COM, no matter how many indirection levels are involved.) Place as many supporting DLLs (including Qt DLLs) in that directory. If you're using Qt plugins, also place the plugins directory there (or use a custom trolltech.conf.)
More details on dot-local redirection here, for example.
This thread looks like it might have the answer to your question:
http://forum.soft32.com/windows/Start-Run-Command-Prompt-ftopict353085.html
In short, I think it might be looking for your executable in different places depending on which method you attempt to use to run it. Perhaps you have 2 different versions hiding somewhere that explorer uses instead of the one you want?
You have not given enough details so I will give you a general answer. In order to use QT and its tools you need 2 environment variables. *QTDIR, and PATH * Make sure you have these variables set instructions are below. I have taken them from this site. See also this link for deployment on windows.
Setup the QTDIR environmental
variable.
1) Create a new System variable
called: QTDIR
a. Right click on My Computer -> Properties -> Advanced Tab ->
Environment Variables button
b. Find System variables -> New -> Type in "QTDIR" 2) Set the value to: C:\your\Qt\directory (NOTICE: No
trailing '\' character!!!)
Now, add the QTDIR on to your PATH
variable.
1) Edit your PATH variable, add onto
the end of it a ';' if one isn't
already on the end. 2) Now add on:
%QTDIR%\bin;
Example:
Before
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;
After,
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%QTDIR%\bin;
That will make sure that our Qt
application(s) will be able to find
the Qt DLL files when you go to run
it.
I hope this helps.
Perhaps there is a difference caused by the way Explorer launches an executable vs directly running it from the console. I think that Explorer uses ShellExecute or ShellExecuteEx and I doubt that executing an application from a console or batch file does the same.
I would create a test app that tries some of the ShellExecute variants and use different parameters to see if the Explorer behavior can be reproduced in order to try to diagnose what parameters passed to ShellExecute might be causing the problem.
There is an interesting community note on the ShellExecuteEx page that may or may not be applicable:
ShellExecuteEx ignores the current input desktop. It always uses winsta0\default. Instead use ShellExecute or CreateProcess.
I would also investigate whether or not AppCompatFlags affect console executed applications (or see if any AppCompatFlags have been set for your application).
In many of my Access (2002) programs I use the GetOpenFileNameA and GetSaveFileNameA functions from comdlg32.dll. I often set the initial directory to the user's My Documents folder (using calls to SHGetSpecialFolderLocation and SHGetPathFromIDListA from shell32). This all works fine under Windows XP.
However, I recently switched to Windows 7 as my development environment and have been getting the following error message:
You can’t open this location using
this program. Please try a different
location.
The function I use to get the My Documents location is returning the correct folder. However, even if I hard code that directory location into the GetOpenFileNameA call, I still get the error.
I came across this post: http://social.msdn.microsoft.com/Forums/en-US/windowsuidevelopment/thread/3391f1dd-25b0-4102-9d5c-58309cc72c9d but, even adapting it to work with Access instead of Excel, I had no luck.
EDIT: Suddenly this is no longer a problem for me. I suspect a windows update went out addressing this issue. Does anyone know if that's true or not?
EDIT: It turns out this is still a problem. Also, in case it helps in the troubleshooting I have found that I get this error message for any of the special folder locations (My Music, My Documents, etc). Also, if I change the location of the My Music folder to, say, C:\Test then I get this message when I try to open the folder C:\Test, while the folder C:\Users\Mike\Music (the original My Music location) opens without a hitch.
Windows 7 adds the concept of a "library", which is basically a virtual folder that includes the contents of at least two actual subdirectories. One place it uses the library is the "My Documents" folder, which (at least by default) is a library that includes both the user's documents directory ("c:\users\whoever\documents") and the public documents directory (C:\users\public\documents").
As such, the basic approach you're using simply can't work -- there is no path that denotes the Documents folder. The documents folder needs to be specified by a PIDL, not a path.
Edit: It's not clear what's going on if you can't open C:\users\user\Documents. A quick test in C++ works fine using code like:
OPENFILENAME data = {0};
wchar_t filename[256] = {0};
data.lpstrInitialDir = L"C:\\users\\jerry\\documents";
data.lStructSize = sizeof(data);
data.lpstrFile = filename;
data.nMaxFile = sizeof(filename);
GetOpenFileName(&data);
OTOH, there's no real need to specify the initial path -- the Documents folder is the default anyway.
The link I posted in my original question (http://social.msdn.microsoft.com/Forums/en-US/windowsuidevelopment/thread/3391f1dd-25b0-4102-9d5c-58309cc72c9d) held the answer after all. I'll summarize things here. To fix this behavior, you need to do away with the STRIPFOLDERBIT flag in the shell compatibility registry entry for all affected programs.
Keep in mind (and this is what tripped me up for so long) that 32-bit programs have entries in a special registry section if you have 64-bit windows. Here's the quick and dirty:
Rename STRIPFOLDERBIT to xSTRIPFOLDERBIT for the following keys (as applicable):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\excel.exe
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\msaccess.exe
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\excel.exe
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\msaccess.exe
Does anyone have a method to overcome the 260 character limit of the MSBuild tool for building Visual Studio projects and solutions from the command line? I'm trying to get the build automated using CruiseControl (CruiseControl.NET isn't an option, so I'm trying to tie it into normal ant scripts) and I keep on running into problems with the length of the paths. To clarify, the problem is in the length of paths of projects referenced in the solution file, as the tool doesn't collapse paths down properly :(
I've also tried using DevEnv which sometimes works and sometimes throws an exception, which isn't good for an automated build on a separate machine. So please don't suggest using this as a replacement.
And to top it all, the project builds fine when using Visual Studio through the normal IDE.
It seems that it is limitation of the MSBuild. We had the same problem, and in the end, we had to get paths shortened, because did not find any other solution that worked properly.
The SUBST command stills seems to exist so remapping the root of your build folder to a drive letter may save some characters if Judah Himango's solution is no good.
I solved similar issue by adjusting CSPROJ-file:
<BaseIntermediateOutputPath>$([System.IO.Path]::GetFullPath('$(MSBuildProjectDirectory)\..\..\..\Intermediate\$(AssemblyName)_$(ProjectGuid)\'))</BaseIntermediateOutputPath>
As the result during compilation CSC.EXE receives full path instead of relative one.
Thanks to harrydev for clue on how CSC.EXE operates with the paths.
There are two kinds of long path problems relevant to build. One is paths that aren't really too long, but have lots of "..\" in them. Typically, these are references' HintPath values. MSBuild should normalize these paths down to below the max limit, so that they work.
The other kind of path is just plain too long. Sorry, but these just won't work. After looking at it a fair bit, the problem is that there just isn't sufficient API support for long paths. The BCL team (see their blog) had similar problems. Only some of the Win32 API's support the \?\ format. Arbitrary build tools, and probably 98% of apps out there, don't; and worse would probably behave badly (think of all the buffers sized for MAX_PATH).
We came to the conclusion that until there's a big ecosystem effort to make long paths work, or Windows comes up with some ingenious way to make them work anyway (like the short paths mangling?) long paths just aren't possible for MSBuild to support. Workarounds include subst, as you found; but if your tree just is simply too deep, your only options are to build it in fragments, or to shorten the folder names. Sorry.
Dan/MSBuild
I found the problem to be that when the C# compiler (csc.exe) is called it uses the projects directory path PROJECTDIRECTORY together with the output path OUTPUTPATH by simply appending them as:
PROJECTDIRECTORY+OUTPUTPATH
However, if the OUTPUTPATH is relative i.e. "..\..\Build\ProjectName\AnyCPU_Debug_Bin\" and the project directory is pretty long then the total length is longer than 259 characters since the path will be:
PROJECTPATH+"..\..\Build\ProjectName\AnyCPU_Debug_Bin\"
instead of an absolute path.
If csc.exe would make an absolute path before calling Win32 functions this would work. Since in our case the absolute path length is less than 160 characters.
For some reason the call to csc.exe from visual studio is then different from MSBuild than it is from visual studio. Do not know why.
In any case, the problem can be resolved by changing either or both PROJECTDIRECTORY and/or OUTPUTPATH paths.
Have you tried DOS paths? Or the \\?\ prefix? The .NET BCL team blog has more info.
If the path length is 260, then there is warning resolving reference, for 259 or 261 of this error does not occur. I think there is msbuild bug.
I know there is already an accepted answer, but I had a different problem while using msbuild that gave me the same error output, and led me on a circular wild-goose chase. So, for future googlers, here goes:
We have a batch file that calls msbuild, but as the build machine can build for multiple versions of Visual Studio, each batch file calls vcvarsall.bat before it runs msbuild. This has the nasty side effect of stuffing the path completely full of the same thing over and over again. When it fills up, you get the error shown in the question above: The input line is too long. A simple Google search could make you think your paths are suddenly too long for msbuild.
In my case, it was as simple as killing the session of cmd.exe and restarting, as this reverted the environment variables to their native state.