JDK-4751669 : JDK has problems with super long filenames generated by jwsdp/jax-rpc
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 7.0se,8.1ee,1.4.0,5.0
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS:
    generic,solaris_8,windows_2000,windows_xp generic,solaris_8,windows_2000,windows_xp
  • CPU: generic,x86
  • Submitted: 2002-09-23
  • Updated: 2005-09-06
  • Resolved: 2005-09-06
Related Reports
Duplicate :  
JDK-6182812 - FileOutputStream constructor throws FileNotFoundException with long file names
Relates :  
JDK-4403166 - File does not support long paths on WIndows NT
Relates :  
JDK-6313799 - Long output pathname on windows causes "The system cannot find the path specified" error
Description
JDK will allow a full-path of LESS THAN 260 bytes (not characters, bytes) only.  Anything longer and an Exception is thrown.  From Windows Native Code's "open()" function.

Attempted File:
C:/ias7/domains/domain1/server1/applications/j2eeapps/ArrayApp_1/ArrayService_War_war/
ArrayServiceServantInterface_ArrayTest_getArrayMixedPrimitiveAndComposite_ResponseStruct_SOAPSerializer.class

Mon Sep 23 12:32:10 MDT 2002	bn80925

Mon Sep 23 12:34:49 MDT 2002	bn80925

Note that in the studio installation this is a little worse because the
s1as7 installation is in:
c:/sun/studio/appserver7/domains/...

Also related is that the studio user directory is another place these files
end up, which is in
c:/documents and settings/Joe User/studio5_se_user/...

But by far the longest component to these names are the jwsdp generated
names.
###@###.### 2004-04-06
Comments
EVALUATION win32 longpath support has been fixed in mustang, see#6182812, it's no longer reproducible in 6.0, close as "dup of 6182812". The backport to 5.0u has been approved/reviewed.
06-09-2005
EVALUATION The example file, that is in a zipfile, had a full path 276 characters long. It is impossible for the current code to explode the file into it's given directory. Ideas for Work-arounds: 1. Use relative instead of absolute paths -- If it were possible, we could change-directory to the App's root directory. That would knock quite a bit off the path. In the example in the description, it would cut-out: C:/ias7/domains/domain1/server1/applications/j2eeapps/ArrayApp_1ArrayApp_1 (76 bytes) Too bad that it is IMPOSSIBLE to change directory at runtime in java!! 1B) We could run the Zip code in a separate VM -- and have the VM start in the right directory. This solution is error-prone and messy. That would make the zip explosion work. Then something else in Deployment will break. As soon as the full-path for one of these files is used, JDK will fail. 2) Use a temp-dir with a short name to explode everything into. When done exploding, copy the tree into the final area. Oops -- JDK will blow up copying the files. So to copy the files, we need to run the copying code in a separate JVM and do the trick with changing the current directory. ***** I think this is hopeless -- there are a million places that uses filepaths. What about the Class Loaders with paths > 260 chars. Etc., I think we need the JVM to start supporting filenames > 260 characters I think Studio needs to create much shorter filenames when it creates Web Services Mon Sep 23 12:51:42 MDT 2002 bn80925 I added some code to the appropriate place in ZipFile.java that checks for filename >= 260. It then throws an official ZipFileException... Thu Sep 26 13:02:09 MDT 2002 bn80925 JAXRPC RI generates long class names. This causes problems with JDK on some platforms. For e.g: C:/ias7/domains/domain1/server1/applications/j2eeapps/ArrayApp_1/ArrayService_War_war/ ArrayServiceServantInterface_ArrayTest_getArrayMixedPrimitiveAndComposite_ResponseStruct_SOAPSerializer.class In the above, appserver itself produces long directory name. Some of the class names are mandated by spec. For e.g: if a complex type has long XML name, the corresponding java bean has long class name. or Service name in WSDL is long, the corresponding class name is long. So I guess we cannot help in many cases w.r.t JAXRPC specification. But RI can reduce some names like "_ResponseStruct_SOAPSerializer". This invovles changes in many files and cannot be done for JWSDP1.4 release. ###@###.### 2004-04-22 I checked a simple java snippet (attached as testbug.java) to verify that the bug still exists in JDK 1.4. It does. You can *create* a 298 character file -- but it can't be opened. Here is the output from the test program: length = 249 null length = 298 java.io.FileNotFoundException: C:\tmp\abcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghij\abcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghij\abcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghij\abcdefghijabcdefghijabcdefghijabcdefghij\bolongo (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:106) at testbug.main(testbug.java:43) ###@###.### 2004-04-22
22-04-2004
SUGGESTED FIX Have the jaxrpc generation use more compact names. ###@###.### 2004-04-06
06-04-2004
WORK AROUND User can create appserver domain in directory named something like: c:\f User can have their userdir be c:\u or something similar. User can have short classnames and method names and a shallow package structure. ###@###.### 2004-04-06
06-04-2004