This is something that is mystifying me.
We have a remote share \SomeMachine\Mirror
with a sub folder \Reports
so
\\SomeMachine\Mirror\Reports
We then have a batch command that runs
md "\\SomeMachine\Mirror\Reports\YYYY\YYYY-MM\YYYY-MM-DD"
where the date parts are substituted for the current date.
I can run this command from my machine and it correctly creates the path,
but from the server (Windows Server 2008 R2), it fails saying "The directory or file cannot be created". Stranger still, if I do the md in stages, first creating the YYYY path then the YYYY-MM path, it works fine. Not sure if there are any permissions that would prevent one method and not the other?
Both command shells state their version as 6.1.7601, and mkdir /? states that it will create intermediate paths.
Anyone have any idea what might be going wrong?
Thanks!
After some investigation on different servers, I confirmed that the behaviour was different between two otherwise identical servers. A restart of the server exhibiting the problem resolved this. There were no other (visible) symptoms, so chalk this up to "glitch" likely linked to a server software update.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 29 days ago.
The community reviewed whether to reopen this question 29 days ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am having a problem executing a bat file. After some time running I get the "input line is too long" error.
The structure of the bat file is simple. There is a main bat file that calls 10 other bat files that are responsible for updating data of my system modules. In the updating data bat files there are lot of calls for a command(.cmd file) of my system that is responsible for updating the data through some calculations.
The point is, when the process was running in a Windows 2003 Server it was ok. No errors.
Then, when it was upgraded to Windows 2008 Server, I execute the main bat file, several hours later I got the "Input line is too long" error. I can't even execute any command included in the updated data bats manually in that cmd window. But if I close the cmd window and open a new one I can execute the commands without errors.
What's the solution to this?
I have had this same problem when executing a build script in a cmd window. After about 13 times I got that same error. The build script had to make sure that vcvarsall.bat was run so it executed vcvarsall.bat every time.
vcvarsall.bat is not smart enough to only add things to the path if they are not already there so a bunch of duplicate entries were added.
My solution was to add an if defined check on an environment variable which I know is set by vcvarsall.bat...
if not defined DevEnvDir (
call vcvarsall.bat
)
Check your path environment variable after each run and see if it is growing. If it is and there are duplicates, you will need to be smart about adding stuff to the path. There are several ways to be smart about it.
I happened upon this error just now for the first time after running the same set of commands (stop / start an application server) a number of times.
The error stopped when I opened up a new command line and tried the commands from the new command line console.
This usually happens due to long path. I have resolved this issue by replacing base path of Kafka from C:\Program Files<Kafka_path> to C:\Kafka
I realize this is pretty old, but the other issue I ran into was having a " at the end of the command I was calling. I was attempting to call:
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\..\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe""
If you notice, I have two " at the end of the line. This was causing my issues (Notepad++ included it when I typed the quotes). Removed that, all good. Again, may not be your issue, but if anyone else comes seeking info and nothing else works, check this. :)
There is a Windows knowledge base article on this subject. They don't mention Windows 2008 server, but they did mention the difference in size between other versions of the OS, so it wouldn't be surprising is there was a difference between 2003 and 2008.
As for solutions to the problem, some of their suggestions include:
Modify programs that require long command lines so that they use a file that contains the parameter information, and then include the name of the file in the command line.
Use shorter names for folders and files.
Reduce the depth of folder trees.
You can read the whole article if you want to see what else they have to say, but those were the suggestions that looked most likely to apply to you.
Rename the folder name to Kafka . It worked fine for me . Close the cmd and start it again . That will definitely work fine !!
Before :
After :
I have the same issue to start zookeeper under window. The root cause is due to file path is too long. I relocated the kafka folder to shorter file path. For example : c:/kafka_2.13-2.6.0. then cd to bin/windows and start zookeeper. It works.
when it's necessary to call vcvarscall.bat multiple times, then:
setlocal
vcvarsall.bat x64
cl xxx.cpp
endlocal
setlocal
vcvarsall.bat x86
cl xxx.cpp
endlocal
It can also happen if the spaces in your file (ansi character 0x20) are really non-breaking spaces (I had 0xA0, but yours may vary). This can happen if you copy/pasted from the internet to a UTF-8 aware editor.
The result depends on the current codepage of windows, your editor and such. To fix:
Use an hexadecimal editor
Look at how spaces are represented
Search and replace your representation
I used HxD to search and replace 0xA0 to 0x20.
using CALL several times to run another batch that sets env will increment the value of the var you are setting,hence the error at some point
call set path=some\path;%path%
running the above command in cmd for many times will produce the error
I ran into this also.
I was trying to run vcvars.bat as others here seem to be trying.
The underlying problem for me seemed to be that my PATH variable was polluted with repeats of an already pretty lengthy path. Fixing up my path seemed to fix the issue for me (in a new terminal, of course). Note that this fix isn't specific to vcvars.bat or anything Visual Studio related.
I'm curious if Cookie Butter's solution is a workaround and the underlying problem is the same.
This happens due to long path or long name of directory . I have resolved this by renaming the folder name by removing the version from it and placing the folder to c: directory.
Example -
from = C:\Users\rsola\Downloads\kafka_2.13-3.3.1
to = C:\kafka
My VB6 program uses Mkdir to create a folder after first confirming that the folder doesn't exist, using this couldn't-be-simpler code:
If LenB(Dir$(ImportFolder & "\" & UuidPartOfImportFolderName, vbDirectory)) = 0 Then
MkDir ImportFolder & "\" & sIECommon2.gstrUniqueImportUuid
End If
When I run this code in my own development environment, from inside the IDE, or even run the .exe on my local machine, it works perfectly--the folder gets created as expected and other files are then successfully created in it.
But when I build the executable and install it on another machine, the Mkdir command throws the error 'Error 75: Path/File Access error'. (I narrowed it down to this command by putting a MsgBox command immediately before and after it--the one before gets displayed, but the one after does not.)
The default permissions on a folder created using Mkdir are rwx for everyone, according to my research ...so why would it throw the error on other machines and not on mine?
Or maybe it has nothing to do with what machine it's running on--I just had no other theories. The other weird thing is that this program has used MkDir in other places for years; I've just added this new one when I added additional functionality.
Thank you--looking forward to your responses.
I suspect that WQW's answer is what's happening, but, you might want to verify that the two machines are running the same version of teh VB6 runtimes (MSVBVM6.dll). There are several versions. It's a long shot but one might behave slightly differently than another.
But again, I kind of doubt that, I suspect the two folder names you're working with aren't exactly the same.
This may be a question for ServerFault but I was more interested in understanding the methodology that the OS uses to resolve relative paths. I have two VMware instances of Windows 2003. I am trying to run a batch file that starts running another batch file within its folder path. The script runs fine on one VM but on the other VM it fails to execute with the error:
> The System cannot find the file specified
The script I am trying to run is script.bat:
start /d FOLDERNAME /b /WAIT AnotherScript.bat %~n0%~x0
I have put both my files within the same folder structure under the C:\ drive on both machines. The file AnotherScript.bat resides within FOLDERNAME on both the VMs.
It is not a permissions issue(?) since I show up as an administrator on both VMs.
I was wondering why would I get an unable to resolve relative paths on one machine vs. the ability to resolve it on another machine.
Thanks
First check if the folder in which both are lauching are the same. Try adding ECHO %CD% before calling the 2nd script to check the directory in which it is getting launched.
Also check if the path where the 2nd bat file resides is set in the %PATH% variable in the 1st VM.
Where does command prompt start by default in both VMs?
I would like to know what are the approaches that you use to manage the executables in your system. For example I have almost everything accessible through the command line, but now I come to the limit of the path string, so i can't add any more dir.
So what do you recommend?
A long time ago, I tried to use softLinks of the executables in a Dir that belonged to the path, but that approach didn't work.
Throw the "executable only" to a known Dir,has the problems that almost any application require a set of files, so this also is bad.
Throw the executable and all his files to a known Dir, mmm this will work, but the possibility to get a conflict in the name of the files is very very high.
Create a HardLink? i don't know. What do you think?
This will parse your %PATH% environment variable and convert each directory to its shortname equivalent and then piece it all back together:
#echo off
SET MyPath=%PATH%
echo %MyPath%
echo --
setlocal EnableDelayedExpansion
SET TempPath="%MyPath:;=";"%"
SET var=
FOR %%a IN (%TempPath%) DO (
IF exist %%~sa (
SET "var=!var!;%%~sa"
) ELSE (
echo %%a does not exist
)
)
echo --
echo !var:~1!
Take the output and update the PATH variable in environment variables.
One way I can think of is to use other environment variables to store partial paths; for example, if you have
C:\this_is_a\long_path\that_appears\in_multiple_places\subdir1;
C:\this_is_a\long_path\that_appears\in_multiple_places\subdir2;
then you can create a new environment variable such as
SET P1=C:\this_is_a\long_path\that_appears\in_multiple_places
after which your original paths become
%P1%\subdir1;
%P1%\subdir2;
EDIT: Another option is to create a bin directory that holds .bat files that point to the appropriate .exe files.
EDIT 2: Ben Voigt's comment to another answer mentions that using other environment variables as suggested might not reduce the length of %PATH% because they would be expanded prior to being stored. This may be true and I have not tested for it. Another option though is to use 8dot3 forms for longer directory names, for example C:\Program Files is typically equivalent to C:\PROGRA~1. You can use dir /x to see the shorter names.
EDIT 3: This simple test leads me to believe Ben Voigt is right.
set test1=hello
set test2=%test1%hello
set test1=bye
echo %test2%
At the end of this, you see output hellohello rather than byehello.
EDIT 4: In case you decide to use batch files to eliminate certain paths from %PATH%, you might be concerned about how to pass on arguments from your batch file to your executable such that the process is transparent (i.e., you won't notice any difference between calling the batch file and calling the executable). I don't have a whole lot of experience writing batch files, but this seems to work fine.
#echo off
rem This batch file points to an executable of the same name
rem that is located in another directory. Specify the directory
rem here:
set actualdir=c:\this_is\an_example_path
rem You do not need to change anything that follows.
set actualfile=%0
set args=%1
:beginloop
if "%1" == "" goto endloop
shift
set args=%args% %1
goto beginloop
:endloop
%actualdir%\%actualfile% %args%
As a general rule, you should be careful about running batch files from the internet, since you can do all sorts of things with batch files such as formatting your hard drive. If you don't trust the code above (which I wrote), you can test it by replacing the line
%actualdir%\%actualfile% %args%
with
echo %actualdir%\%actualfile% %args%
Ideally you should know exactly what every line does before you run it.
if you are using windows vista or higher, you can make a symbolic link to the folder. for example:
mklink /d C:\pf "C:\Program Files"
would make a link so c:\pf would be your program files folder. I shaved off 300 characters from my path by using this trick.
In case anyone's interested...
I find I never really need all those paths at once, so I create a bunch of "initialization" batch files which modify the path accordingly.
For example, if I wanted to do some C++ development in Eclipse, I would do:
> initmingw
> initeclipse
> eclipse
This is also handy for avoiding conflicts between executables with the same name (such as the C++ and D compilers, which both have a make.exe).
My batch files typically look like this:
#echo off
set PATH=C:\Path\To\My\Stuff1;%PATH%
set PATH=C:\Path\To\My\Stuff2;%PATH%
I find this approach relatively clean and have yet to run into any problems with it.
I generally don't have to worry about this (I haven't run into a path size limit - I don't even know what that is on modern Windows systems), but here's what I might do to avoid putting a program's directory in the path:
most command line utilities get thrown into a c:\util directory that's on the path
otherwise, I'll add a simple cmd/batch file to the c:\util directory that looks something like:
#"c:\program files\whereever\foo.exe" %*
which essentially creates an alias for the command. It's not necessarily perfect. Some programs really insist on being in the path (that's pretty rare nowadays), and other programs that try to invoke it might not find it properly. But for most uses it works well.
But generally, I haven't had to worry about avoiding adding directories to the path.
Another idea: Use DIR /X to determine the short names generated for non-8dot3 file
names. Then use these in your %PATH%.
For example, 'C:\Program Files' becomes 'C:\PROGRA~1'.
USe the App Path registry key instead of the path variable for application-specific paths:
http://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx
I wrote and use on a every-time basis a standard stream (stdin/stderr/stdout) & exit code PROXY program (called dispatcher https://github.com/131/dispatcher)
All CLI program i use (node, php, python, git, svn, rsync, plink ...) i'm using are actually the same exe file (around 10kb, that i just name differently), that i put in the same directory. A dummy static clear text file do the "proxy file name to real exe mapping".
Dispatcher use low level Process management win32 API to be absolutly transparent.
Using this software, i only do have ONE additionnal directory set in my PATH for all programs i might use.
Creating a folder c:\bin adding to your path and hardlinking like you said could shorten the string. Maybe add a variable pf to system vars with value c:\Program Files then replace c:\Program Files with %pf% in path.
Edit:
Create a virtual drive.
subst p: "c:\program files"
I follow these steps to make the entries manageable:
Created different users for different combination of software packages usage.
Example: (a) Created a user web for making available all the web development software; (b) Created a user database for making available all the database and data warehousing software packages. Remember some software may create more than one entry. Or sometime I break this into oracle specific and MSSQL specific and oracle specific users. I put MySQL/PostgreSQL, tomcat, wamp, xamp all into the user account webr.
If possible install common packages like office, photoshop, .. as system specific available for all users and special packages as user specific. Of course I had to log into different users and install them. Not all software may provide this option. If "install for this user only" option is not available, install it for the whole system.
I avoid installing programs in to the folder Program File (x86) or in to Program File. I always install into the base directory. For example MySQL 64 bit goes into "C:\mysql64" and MySQL 32 bit goes into "C:\mysql" folder. I always assume adding a suffix 64 only for 64bit software. If no suffix, then it is a 32 bit. I follow the same thing to Java and others. This way my path will be shorter, not including "C:\Program File (x86)". For some software the configuration file may need to be edited to show where exactly the .exe file is. Only program that demands to be installed into "C:\Program File (x86)" will be installed into that folder. Always I remember to shorten the names. I avoid version number like tomcat/release/version-2.5.0.3 such details. If I need to the know version, I create a file by name version and put it into the tomcat folder. In general shorten the link as much as possible.
Include any batch to replace abbreviated link to the path, if all the above steps passed the Windows limit.
Then Log into usage specific (mobile application, or database/data warehousing or web-development.. ..) user and do the relevant tasks.
You can also create virtual windows within windows. As long as you have one licensed OS copy, creating multiple virtual windows with same key is possible. You can put packages specific for a particular task in that machine. You have to launch separate VM each time. Some memory intensive packages like 3D animation movie makers all should be put into the main machine, not into VM as VM will have only a part of the RAM available for its use. It is a pain to boot each VM though.
The solutions above only work if you can trim down your path. In my case, that wasn't really an option, and it was a hassle to have to run a script every time I opened a command prompt. So I wrote a simple script that runs automatically when opening the command prompt, and appends the contents of a text file to your path.
There are also some contexts where having this script run breaks things (say, in a github or cygwin shell), so I also added a file that contains a list of paths that, if the command prompt is started in them, the path variable isn't changed via the startup script that normally updates the path.
#echo off
:: Modify these to the actual paths of these two files
set dontSetupFile=C:\Users\Yams\Dontsetup.txt
set pathFile=C:\Users\Yams\Path.txt
:: Retrieve the current path (for determining whether or not we should append to our path)
set curDir=%cd%
:: Be done if the current path is listed in the dontSetupFile
SetLocal EnableDelayedExpansion
for /F "delims=" %%i in (%dontSetupFile%) do (
if "%%i"=="%curDir%" GOTO AllDone
)
:: Append the pathFile to our current PATH
set pathAppend=
for /F "delims=" %%i in (%pathFile%) do (set pathAppend=!pathAppend!%%i)
set PATH=%PATH%;%pathAppend%
:: The only way to actually modify a command prompt's path via a batch file is by starting
:: up another command prompt window. So we will do this, however, if this script is
:: automatically called on startup of any command prompt window, it will infinately
:: recurse and bad things will happen.
:: If we already ran, we are done
if "%yams%"=="onion" GOTO AllDone
:: Otherwise, flag that we just ran, and then start up a new command prompt window
:: with this flag set
set yams=onion
cmd \K set PATH=%PATH%;
:: When that command prompt exits, it will load back up this command prompt window, and
:: then the user will need to exit out of this as well. This causes this window to
:: automatically exit once the cmd it just spawned is closed.
exit()
:: Path is set up, we are done!
:AllDone
#echo on
And Path.txt will look something like
C:\Program Files (x86)\Google\google_appengine;
C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;
C:\Program Files\Microsoft SQL Server\110\Tools\Binn;
C:\Program Files\Microsoft DNX\Dnvm;
C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit;
While Dontsetup.txt will look something like
C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit
C:\Program Files (x86)\Git\cmd
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin
To make this run automatically on startup, open regedit, navigate to HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Command Processor, then right click on the right and press new -> Multi-String Value. Name it AutoRun. Set it's value to
C:\Users\Yams\setUpPath.bat
or wherever else you stored the batch file above.
Didn't try it, but will splitting PATH in parts work and joining them in final variable work?
Example initially let's say you have something like
PATH={LONGPATH1};{LONGPATH2};....{2048th char}....{LONGPATH_N-1};{LONGPATH_N}
Instead you create:
_PATH1 = {LONGPATH1};{LONGPATH2};....{2048 char}
_PATH2 = {2049th char}...{LONGPATH_N-1};{LONGPATH_N}
rem // may be more parts
PATH = %_PATH1%;%_PATH2%
I'm having a weird problem with running cl.exe that has me stumped. In a large VS2008 solution consisting of C/C++ projects, I have one project that runs some scripts to do some extra processing. The project consists of a pre-build event, which calls a Perl script (ActiveState Perl is on the machine). This Perl script then calls cl.exe with /E to generate preprocessed output which gets redirected to a file. The line in Perl looks like this:
my $foo = `"\path\to\cl.exe" #args.rsp >out.txt 2>err.txt`;
args.rsp is a plain text file that contains a bunch of command line args for cl.exe, including /E to get pre-processor output on stdout.
This exact command line works as expected when run from the VS2008 command prompt. Building the project also works fine on my Windows XP machine. However, on my new Windows 7 box, when I build the project, out.txt ends up blank. I should also add that on some of my coworker's Windows 7 boxes, it works fine, and on some others it doesn't.
Clearly there's some kind of configuration difference going on, but I'm at a loss as to what it may be. We've checked matching versions of VS2008 SP1 and ActiveState Perl. I've tried myriad workarounds within the perl script - using system() instead of backticks, using cl.exe /P to output to a file and then moving the file (the file is blank), unsetting the VS_UNICODE_OUTPUT environment variable (no effect). Nothing has changed the behavior - output is generated when the command line is run manually, but not when it's run inside the pre-build event for this project.
Any ideas on what kind of configuration problem may be causing this? I'm pretty much out of avenues to pursue.
Sounds like an ACL issue to me. You can change windows to log access issues and then check the event log to see what user is getting access denied errors.
I believe the setting is in Local Policy | Audit Policy | Audit Object Access
Wow, the solution to this ended up being a lot stranger than I expected. The machine I'm working on (and the other co-workers who are also experiencing the problem) is a Mac Pro with bootcamp and Windows 7 installed. That causes C: to have the windows drive and E: to have the mac drive. This causes a problem because the pre-build event has a couple lines that test each drive letter to see if there's a drive there, and if there is, adds X:\Perl\bin to the path. Even though E:\Perl\bin doesn't exist, it gets added to the path. Later, the perl script runs and then calls cl.exe, and for some reason, having a directory in the mac drive causes cl.exe to fail. Why? I have no idea. Anyway, removing the mac drive directory from the path fixes the problem!
Thanks for your eyes everyone.
Check out the exit code of your program. You may want to build your executable name in a portable way using something like File::Spec. Also, check that #args is not interpolating. You may want to print your command line before executing to check if that's what you want. What is left your err.txt file?