This could not be the reason because the path where I installed dspace is much shorter (E:\STIR). What I've found out when I'm also looking for this type of message is that (sorry, couldn't find the page where I've seen them) the batch file is appending the environment variable (in my case DSPACE_CLASSPATH) in the input but it is not cleaning up the variable after executing java:
REM Execute Java
java %JAVA_OPTS% -classpath "%DSPACE_CLASSPATH%" org.dspace.app.launcher.ScriptLauncher %*
REM Clean up DSPACE_CLASSPATH variable
set DSPACE_CLASSPATH=
I believe this could be the reason for the message because when I execute the command "set", the DSPACE_CLASSPATH variable is still there. As I've mentioned in my previous post, I tried to checkout a new 6.3 branch in a different directory and set the install location also in a new directory but still I received the same error message when executing the dspace batch file. Copying the batch files from the first instance of dspace that is working gave me "The input line is too long" message also.
I've also mentioned in my previous post that I have two DSpace instance in this server and that the first instance worked ok. I forgot to mention that the first instance is located in a different partition. The solution I found (well, not really a solution but a workaround) is to checkout a new branch in a different partition (where the first DSpace instance also resides) and build from there. Even though I still set its install directory in its original location, executing the dspace command is now working perfectly. I am still wondering what could be the cause of that message and I can't remember anything that I did to trigger that since it is working perfectly for months.
Thanks again and I apologize for those who may have the same error but have only one partition in their server because my workaround will not be applicable for your case.
Sincerely,
euler