formenko: which build it was?  Without the build number and
reproducible test case the bug report would be regarded as INVALID

I don`t think this is problem of filesystems. There is created new 
FileObject using createData with suspicious name: 
F#003A#005Cforte4j#005Cf4j_all#005Cf4jce#005Ctests#005Cj2eeserver#005C
testbase#005Csrc#005Cweb#005CStubJspModule
#003A#002FWEB-INF#002Fclasses.settings. Please be aware of the fact 
that at least FAT doesn`t allow such lenght and also NTFS has some 
limits. 

Jan please look at this bug (reassigned to Jan Pokorsky).

[W2k, jdk1.3.1_01, nb20011101]
Hmm, I've tried to create a file with the same name using 
FileUtil.createDate without any problem in LocalFileSystem.

Anyway Netbeans are platform independent so why should the settings 
implementation take FAT, NTFS, ... into account? That is job for lower 
layers (filesystems/JVM/OS) IMO. At least Filesystem API say nothing 
about length of a file name.

Assigned back to Radek

Probably I made wrong conclusion with length of filename.

But I must insist that such long filenames are useless and at least 
has huge impact for performance. (FYI: lenght of this filename didn`t 
cause any problems on my machine, but filenames about 255 chars did.)
You are right that in documentation isn`t length of filename limited. 
So, I correct it and I think that recommended maximum could be about 
30 chars. Also I think that it could be confusing for users if 
FileObject.filenames did not correspond to OS.FS.filenames.

Message "There are no more files" implies that problem could be 
number of open FileHandles per process. In my test (on Win2000 with 
NTFS) was fired exception from createFileExclusively after creating 
2042 referenced FileInputStreams. 

I decrease priority and will wait for more info to have any hint. If 
you had test case, then definitely increase priority again.

Radek,

increasing the priority would be useful since it's a showstopper for
our tests. Will you be able to execute fjscrip tonga tests from ffj
repository? I can point you to the precise test then.

Anatoli

Perhaps I could run ffjscript. But I don`t think this is bug in 
filesystems. FileSystems library helps you work with files in uniform 
manner but can`t be responsible for excessive usage of files or lack 
of discipline (e.g. not close open streams). Every module can cause 
this Exception. Also this exception doesn`t relate to FileObjects at 
all (it`s enough to get excessive number of FileInputStreams). But I 
understand that it is hard to make decission what`s the cause. 

So I think that best solution would be get more info, investigate 
problem more deeply on your side and wait for results. 
Perhaps you could try disable any module and watch if it helps.

You can watch handle count. The easiest way is usage of TaskManager. 
Also you could use performance monitor (PerfMon.exe). Add new 
counter, choose process as performance object and handle count as 
counter. Choose log file (or set up alert).  Then run your test or 
test suite. And evaluate peeks of handle count from your log. If you 
know how to get limits of handle count per process then compare them 
(I don`t know how to get this information and how to change this 
limit in WinNT). 

Also usage of FileMonitor (e.g. FileMon, NTFileMon ..) could help.

Is this issue still acute ? Or did you find problem ? In any case I 
have no clue to be able to continue. Any comments ?

If you can run fjscript tests in tonga, please try 'ant web-test' in
f4j_all/f4jce/tests/j2eeserver/testbase

As I mentioned in my previous comment: I don`t think this is bug in 
filesystems. This bug may be caused by any modulle or by fjscript 
tests (everythink can cause this bug). I`ll close this bug. If you 
don`t agree than be free and reopen, but then I think that Anatoli or 
people in QA could be able to run fjscript tests in tonga. It would 
be very helpfull if anybody from QA could run 
f4j_all/f4jce/tests/j2eeserver/testbase and verify if this bug is 
valid and get more info about opened handles according previous 
comments. If there appears any sign that problem is in filesystems 
then reassign back, else reassign appropiately.

I executed described tests on Solaris and Windows NT using latest CE
and EE builds and on both platforms everything finished without
problems. On NT I checked handle counts and they were cca 580 on CE
and 690 on EE - no problem for NT. Once I saw 'filename too long'
exception from windows native code - but with this we cannot do
anything here. Please run the test and use Performance monitor or Task
manager and check handle count on your side. I see this issue as not
reproducible.

Created attachment 3679 [details]
Simple test case

The newly attached testcase (by jskrivanek) demonstrates the bug 
quite easily. Please note that the length of the file path seem to 
cause the problem, not the actual number of open file handles.

I'm reopening the issue until the new test case is evaluated.

*** Issue 18322 has been marked as a duplicate of this issue. ***

Seems that problem is really length of filename. I think that this 
bug is potential time bomb. I publicly declared that I don`t plan to 
support long names in filesystems in release33 (I also think that 
such support should be used goldenly in future). Please cut lenght of 
filenames in InstanceDataObject. I think that method like cutEncode 
could be safe. But is not reversible (I`m not sure if necessary - 
please evaluate). Then could be used in IDO:
fileName = cutEncode (escape (fileName)). AFAIK: you should  
synchronize yourself with Dafe and its usage of IDO in 
PersistentManager.

private static String cutEncode (String name, int maxLen) {        
    if (name.length() <= maxLen)  return name;
    String hash = new Integer (name.hashCode()).toString();
    maxLen = (maxLen > hash.length()) ? (maxLen-hash.length())/2 :1;
    String start = name.substring(0,maxLen);        
    String end = name.substring(name.length() - 
maxLen);                    
    
    return start + hash + end;
}

It is potential data loss. Increased priority to P2. See also  
discussion in thread 
http://www.netbeans.org/servlets/ReadMsg?msgId=210211&listName=nbdev

I will implement some workaround in InstanceDataObject but I'm still 
convinced the filesystem api should provide some support handling long 
filenames and forbidden characters in filenames in next release.

The length of filenames also causes big problems to XTest testing
framework, because when tests are trying to mount their working
directory (which is quite often very deep in the directory structure,
bcasue of CVS and java packages), IDE throws the reported exception
and there is a high posibility that the whole test run fails.

For example (from Solaris), in XTest there is no problem to have in
${ide.user}/Projects/Default/system/Mount/ such a file:
#002Fspace#002Fbreh#002Fxtest#002Fdriver-test#002Fcvs#002Ff4j_all#002Ff4jce#002Ftests#002Fexamples#002Ftest#002Fworkdir#002Fsystemworkdir#002Fide_userdir#002Fjspwork#002FTomcat+3#002E2#002F3e8ef54b.settings

This might be ok on Solaris, but cause big problems on Windows.

Please also note, that although we're talking about length of
filename, on Windows there is also problem with length of path
pointing to that file. So I can have a file with name 100 chars long,
but if I will point at this file not from the directory where it is
stored, then everything will be ok. But if I try to do it from the
root (e.g. c:\) the same operation will fail! So on windows it looks
like you can create a file with the length of name up to 256 chars,
but this also includes path!!!!

Anyway, IMHO use of such a long filenames is not wise at all and
should be redesgined ASAP (at least temporarily cut the length of the
filename to 20 chars or so). 

Fixed in the release33 branch. IDO.create cuts filenames longer than 
50 chars as was recommended by Radek M. If the filename is longer its 
midle part is replaced by hash code of escaped original name.

I also had to change the algorithm implemented in window system 
(PersistentManager) which was using IDO.create method and IDO.escape 
copy.

Fix affects just newly created files. Passing the filename of an 
existing file to IDO.create works as bofore. So it is backward 
compatible.

http://www.netbeans.org/source/browse/openide/src/org/openide/loaders/
InstanceDataObject.java.diff?r1=1.113.2.2&r2=1.113.2.3
http://www.netbeans.org/source/browse/core/src/org/netbeans/core/windo
ws/PersistenceManager.java.diff?r1=1.20.4.2&r2=1.20.4.3

And here is the unit test
http://www.netbeans.org/source/browse/openide/test/unit/src/org/openid
e/loaders/InstanceDataObjectTest.java.diff?r1=1.15&r2=1.15.2.1

Created attachment 3721 [details]
Here is the patch patch-17186.jar containing fixed classes. Place into {nbuser.home}/lib/patches

fixed in the release330 branch

Verified in release33 and release330 + patch.

Resolved for 3.4.x or earlier, no new info since then -> closing.