We had a strange problem one day when we were trying to deploy an Enterprise Application on WebSphere™ Application Server installed on a Windows XP machine. The application was never getting deployed although it was a perfectly valid one with no errors whatsoever. Just before the application would be deployed completely, a FileNotFoundException was being thrown for the EJB deployment descriptor.

java.io.FileNotFoundException: D:\IBM\..214 characters more ..\ibm-ejb-jar-bnd.xmi (The system cannot
find the path specified)
    at java.io.FileOutputStream.open(Native Method)
    at java.io.FileOutputStream.(FileOutputStream.java(Compiled Code))
    at java.io.FileOutputStream.(FileOutputStream.java:151)
    at com.ibm.ws.management.application.task.ConfigRepoHelper.save2File(ConfigRepoHelper.java:440)
    at com.ibm.ws.management.application.task.ConfigRepoHelper.saveArchiveConfigDocs(ConfigRepoHelper.java:406)
    at com.ibm.ws.management.application.task.ConfigRepoHelper.saveEarConfigDocs(ConfigRepoHelper.java:343)
    at com.ibm.ws.management.application.task.ConfigureTask.performTask(ConfigureTask.java:161)
    at com.ibm.ws.management.application.SchedulerImpl.run(SchedulerImpl.java:215)
    at java.lang.Thread.run(Thread.java:568)

The enigma resolved

The reason is rather very strange. When an application is deployed on an Application Server such as the IBM’s WebSphere™, it creates a sophisticated system of directories which is often deeply nested. Typically the nesting can extend up to 15 levels deep. The names used for this directory structure is based on the name of the Enterprise Application itself. All this is flawless unless the operating system on which the Application Server is installed follows NTFS file system.

Ours was one such case with Windows XP being a follower of this file system. NTFS has following features when it comes to length of file names:

  • The maximum length of a file’s name is dependant on the physical location of the file. In NTFS, the allowable maximum length for a file’s name is calculated based on its absolute path. This means that the length of a file’s name is not just the length of the name of that file. It is a sum of the length of the absolute path of the file and the length of its actual name. For instance, if we have a file called LongFileName.extension (22 characters) located in C:\Windows directory, the length of its name is interpreted to be the length of C:\Windows\LongFileName.extension which is 33 characters.
  • The maximum limit for length of names for files is 260 characters.

Windows just can’t handle files with long names. It behaves very unexpectedly. You can not create a file in a directory where its name (including the absolute path) exceeds the 260 characters limit. Sometimes, you can even expect an error stating that the Recycle Bin can not store long file names when you try to delete such files.

This was the problem with our application - Windows rather. During deployment, the Application Server was trying to create some files (Deployment Descriptor and others) whose absolute path was very long. These files had names based on the name of our Enterprise Application which itself was very long. In essence, the 260 character limit was being exceeded. As a result of this, the files were simply not getting created. Hence, the FileNotFoundException caught during deployment. So, choose the names for your Enterprise Applications carefully!



MSDN has an excellent resource on file name limitations in Windows operating systems.


comments powered by Disqus