Re: Warning regarding Windows file path lengths with JDK 1.4
2006/1/11, John Sisson [EMAIL PROTECTED]: Do people think that the above workarounds are acceptable and it isn't worth trying to shorten our file paths? Hi, Certainly, it's not worth its time, imho. As you wrote we can't do much to work it out, and the only feasible solutions are just workarounds that might not work well, either. I think we could list some possible workarounds (like installing Geronimo into a location with a shorter path) in Wiki to let people know they're not lost when dealing with these path-length issues. Thanks John for your time digging up the answer. I didn't know about the issue till your post. John Jacek
Re: Warning regarding Windows file path lengths with JDK 1.4
Can we recommend a maximum path size for Windows when unpacking the zip and/or installing from the installer? If so, it might be helpful for windows users and avoid some unnecessary problems. We should be able to come up with a general recommendation for the install location and applications to be deployed based upon our default structure and names. We might even be able to incorporate the recommendations via warnings in our installer and deploy tools when the server is running on windows if the recommendation is exceeded. Joe Jacek Laskowski wrote: 2006/1/11, John Sisson [EMAIL PROTECTED]: Do people think that the above workarounds are acceptable and it isn't worth trying to shorten our file paths? Hi, Certainly, it's not worth its time, imho. As you wrote we can't do much to work it out, and the only feasible solutions are just workarounds that might not work well, either. I think we could list some possible workarounds (like installing Geronimo into a location with a shorter path) in Wiki to let people know they're not lost when dealing with these path-length issues. Thanks John for your time digging up the answer. I didn't know about the issue till your post. John Jacek -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Warning regarding Windows file path lengths with JDK 1.4
I'm not sure which scenarios are failing due to this JDK bug but perhaps in some cases we could take advantage of the 8.3 version of the filenames that are automatically generated on Windows referring to the long filenames. See http://en.wikipedia.org/wiki/8.3 Again, not being sure which scenarios are failing I don't know if this helps us or not. Paul On 1/8/06, John Sisson [EMAIL PROTECTED] wrote: FYI.. We need to be careful of resulting file path lengths on Windowswhen creating web applications that may result in long file paths inGeronimo due to a JDK 1.4 bug ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182812) that hasonly been fixed in JDK 1.5_06.Fom reading the bug and related bugs' descriptions it appears theWindows JDK will only allow file names less than 260 bytes, otherwise a FileNotFoundException is thrown.I initially ran into this JDK bug whilst building geronimo under a longdirectory name (see GERONIMO-1428 for details).On a related note (not due to the JDK bug) I found that if I installed geronimo from a zip distribution using WinZip (version 10.0 6685) into along directory path, WinZip also has problems:Error:The system cannot find the path specified.Cannot createC:\test\this\is\a\really\long\install\directory\name\to\demonstrate\jdk\bug\6182812\geronimo- 1.0-SNAPSHOT\config-store\28\geronimo-console-standard-1.0-SNAPSHOT.war\WEB-INF\classes\org\apache\geronimo\console\jmsmanager\JMSConnectionFactoryManagerPortlet.classRegards,John
Re: Warning regarding Windows file path lengths with JDK 1.4
Sounds reasonable to me... Though you left out the last contingency... Which is to go get a Mac ;-) --jason -Original Message- From: John Sisson [EMAIL PROTECTED] Date: Wed, 11 Jan 2006 12:29:31 To:dev@geronimo.apache.org Subject: Re: Warning regarding Windows file path lengths with JDK 1.4 Mapping the file name would reduce the length a bit, but i am wondering if it is really worth the complexity for the small gain in reduction of characters in the file path. For users on JDK 1.5_06 (where the JDK bug is fixed), there are still some related issues that I found after further investigation.. A lot of windows programs are coded to use MAX_PATH, which is defined as 260 characters. If the windows unicode API is used to create the file, paths longer than 256 characters can be used, which is what the JDK bug fix does AFAIK. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/naming_a_file.asp Examples of Windows XP programs that have problems with long file paths are windows explorer and the the CMD shell (I tried them). Hopefully decent backup programs work with paths greater than 260 chars.. WinZip is another example of a program that has problems, so as a workaround users on JDK 1.5_06 can extract the zip with the JDK jar utility (I have confirmed it worked with the following command): C:\test\this\is\a\really\long\install\directory\name\to\demonstrate\jdk\bug\6182812C:\Program Files\Java\jdk1.5.0_06\bin\jar xvf geronimo-tomcat-j2ee-1.0.zip Another workaround for users on JDK 1.4.2 is to install to a different (shorter) location, or shorten file names in their web applications. Do people think that the above workarounds are acceptable and it isn't worth trying to shorten our file paths? John Alan D. Cabrera wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Sisson wrote, On 1/7/2006 10:46 PM: FYI.. We need to be careful of resulting file path lengths on Windows when creating web applications that may result in long file paths in Geronimo due to a JDK 1.4 bug ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182812) that has only been fixed in JDK 1.5_06. Fom reading the bug and related bugs' descriptions it appears the Windows JDK will only allow file names less than 260 bytes, otherwise a FileNotFoundException is thrown. I initially ran into this JDK bug whilst building geronimo under a long directory name (see GERONIMO-1428 for details). On a related note (not due to the JDK bug) I found that if I installed geronimo from a zip distribution using WinZip (version 10.0 6685) into a long directory path, WinZip also has problems: Error: The system cannot find the path specified. Cannot create C:\test\this\is\a\really\long\install\directory\name\to\demonstrate\jdk\bug\6182812\geronimo-1.0-SNAPSHOT\config-store\28\geronimo-console-standard-1.0-SNAPSHOT.war\WEB-INF\classes\org\apache\geronimo\console\jmsmanager\JMSConnectionFactoryManagerPortlet.class Regards, John We can mitigate this problem by mapping the unpacked war name to something smaller, i.e. war_001. WDYT? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDwUDD1xC6qnMLUpYRArvsAJ0WCeI4ndmqyx4B84Uo1yWiWp1gdgCeKC+Z 831EwbUu/DomYsoNd4NLoY8= =9MNW -END PGP SIGNATURE-
Re: Warning regarding Windows file path lengths with JDK 1.4
Mapping the file name would reduce the length a bit, but i am wondering if it is really worth the complexity for the small gain in reduction of characters in the file path. For users on JDK 1.5_06 (where the JDK bug is fixed), there are still some related issues that I found after further investigation.. A lot of windows programs are coded to use MAX_PATH, which is defined as 260 characters. If the windows unicode API is used to create the file, paths longer than 256 characters can be used, which is what the JDK bug fix does AFAIK. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/naming_a_file.asp Examples of Windows XP programs that have problems with long file paths are windows explorer and the the CMD shell (I tried them). Hopefully decent backup programs work with paths greater than 260 chars.. WinZip is another example of a program that has problems, so as a workaround users on JDK 1.5_06 can extract the zip with the JDK jar utility (I have confirmed it worked with the following command): C:\test\this\is\a\really\long\install\directory\name\to\demonstrate\jdk\bug\6182812C:\Program Files\Java\jdk1.5.0_06\bin\jar xvf geronimo-tomcat-j2ee-1.0.zip Another workaround for users on JDK 1.4.2 is to install to a different (shorter) location, or shorten file names in their web applications. Do people think that the above workarounds are acceptable and it isn't worth trying to shorten our file paths? John Alan D. Cabrera wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Sisson wrote, On 1/7/2006 10:46 PM: FYI.. We need to be careful of resulting file path lengths on Windows when creating web applications that may result in long file paths in Geronimo due to a JDK 1.4 bug ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182812) that has only been fixed in JDK 1.5_06. Fom reading the bug and related bugs' descriptions it appears the Windows JDK will only allow file names less than 260 bytes, otherwise a FileNotFoundException is thrown. I initially ran into this JDK bug whilst building geronimo under a long directory name (see GERONIMO-1428 for details). On a related note (not due to the JDK bug) I found that if I installed geronimo from a zip distribution using WinZip (version 10.0 6685) into a long directory path, WinZip also has problems: Error: The system cannot find the path specified. Cannot create C:\test\this\is\a\really\long\install\directory\name\to\demonstrate\jdk\bug\6182812\geronimo-1.0-SNAPSHOT\config-store\28\geronimo-console-standard-1.0-SNAPSHOT.war\WEB-INF\classes\org\apache\geronimo\console\jmsmanager\JMSConnectionFactoryManagerPortlet.class Regards, John We can mitigate this problem by mapping the unpacked war name to something smaller, i.e. war_001. WDYT? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDwUDD1xC6qnMLUpYRArvsAJ0WCeI4ndmqyx4B84Uo1yWiWp1gdgCeKC+Z 831EwbUu/DomYsoNd4NLoY8= =9MNW -END PGP SIGNATURE-
Re: Warning regarding Windows file path lengths with JDK 1.4
On 1/10/2006 5:29 PM, John Sisson wrote: Mapping the file name would reduce the length a bit, but i am wondering if it is really worth the complexity for the small gain in reduction of characters in the file path. For users on JDK 1.5_06 (where the JDK bug is fixed), there are still some related issues that I found after further investigation.. A lot of windows programs are coded to use MAX_PATH, which is defined as 260 characters. If the windows unicode API is used to create the file, paths longer than 256 characters can be used, which is what the JDK bug fix does AFAIK. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/naming_a_file.asp Examples of Windows XP programs that have problems with long file paths are windows explorer and the the CMD shell (I tried them). Hopefully decent backup programs work with paths greater than 260 chars.. WinZip is another example of a program that has problems, so as a workaround users on JDK 1.5_06 can extract the zip with the JDK jar utility (I have confirmed it worked with the following command): C:\test\this\is\a\really\long\install\directory\name\to\demonstrate\jdk\bug\6182812C:\Program Files\Java\jdk1.5.0_06\bin\jar xvf geronimo-tomcat-j2ee-1.0.zip Another workaround for users on JDK 1.4.2 is to install to a different (shorter) location, or shorten file names in their web applications. Do people think that the above workarounds are acceptable and it isn't worth trying to shorten our file paths? Makes sense to me. Regards, Alan
Re: Warning regarding Windows file path lengths with JDK 1.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Sisson wrote, On 1/7/2006 10:46 PM: FYI.. We need to be careful of resulting file path lengths on Windows when creating web applications that may result in long file paths in Geronimo due to a JDK 1.4 bug ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182812) that has only been fixed in JDK 1.5_06. Fom reading the bug and related bugs' descriptions it appears the Windows JDK will only allow file names less than 260 bytes, otherwise a FileNotFoundException is thrown. I initially ran into this JDK bug whilst building geronimo under a long directory name (see GERONIMO-1428 for details). On a related note (not due to the JDK bug) I found that if I installed geronimo from a zip distribution using WinZip (version 10.0 6685) into a long directory path, WinZip also has problems: Error: The system cannot find the path specified. Cannot create C:\test\this\is\a\really\long\install\directory\name\to\demonstrate\jdk\bug\6182812\geronimo-1.0-SNAPSHOT\config-store\28\geronimo-console-standard-1.0-SNAPSHOT.war\WEB-INF\classes\org\apache\geronimo\console\jmsmanager\JMSConnectionFactoryManagerPortlet.class Regards, John We can mitigate this problem by mapping the unpacked war name to something smaller, i.e. war_001. WDYT? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDwUDD1xC6qnMLUpYRArvsAJ0WCeI4ndmqyx4B84Uo1yWiWp1gdgCeKC+Z 831EwbUu/DomYsoNd4NLoY8= =9MNW -END PGP SIGNATURE-
Warning regarding Windows file path lengths with JDK 1.4
FYI.. We need to be careful of resulting file path lengths on Windows when creating web applications that may result in long file paths in Geronimo due to a JDK 1.4 bug ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182812) that has only been fixed in JDK 1.5_06. Fom reading the bug and related bugs' descriptions it appears the Windows JDK will only allow file names less than 260 bytes, otherwise a FileNotFoundException is thrown. I initially ran into this JDK bug whilst building geronimo under a long directory name (see GERONIMO-1428 for details). On a related note (not due to the JDK bug) I found that if I installed geronimo from a zip distribution using WinZip (version 10.0 6685) into a long directory path, WinZip also has problems: Error: The system cannot find the path specified. Cannot create C:\test\this\is\a\really\long\install\directory\name\to\demonstrate\jdk\bug\6182812\geronimo-1.0-SNAPSHOT\config-store\28\geronimo-console-standard-1.0-SNAPSHOT.war\WEB-INF\classes\org\apache\geronimo\console\jmsmanager\JMSConnectionFactoryManagerPortlet.class Regards, John
