This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Pretty trivial to reproduce, at least on Linux. Start the IDE. Now type $ mkdir $userdir/sampledir/foo. and choose Refresh Folder on $userdir/sampledir in the Explorer. A DefaultDataObject appears with the display name "foo.". Bean Browser shows that the FileObject is marked as a file, not a directory, and further that getPath() is "foo", not "foo." as it should be. dstrupl's commit 1.57 to FileObject is probably responsible. This is a regression. I strongly recommend that Filesystems API unit tests be written to cover every interesting situation involving dots in filenames, since this area of the code is historically very buggy. Also consider having AbstractFolder.getPath just use a precomputed string. If you ever look at profiler results you will see getPath (or previously getPackageNameExt) being called over and over and consuming a lot of time. I would suggest the path just be computed and stored in the file object's constructor, since it is used so often.
It is reproducible in [nb_dev](20021009), IMHO it isn't reproducible in the sierra fcs. If you try to create folder "xx." by the IDE (New Folder) IllegalArgumentException arise (see attachment) - only [nb_dev](20021009).
Created attachment 7621 [details] IllegalArgumentException after creation folder "ll."
Use in java application folders ending in dots is not good idea. Because e.g. on Windows there is not possible to create file/folder ending in dots at all. Fixed in trunk with tests for xtest harness.
verified[200210160100].