I'd like to suggest a different solution to this problem. Well, first
let's see what the problem really is, and what was the motivation for
creating MasterFileSystem in the first place. From what I heard, the
motivations were the following:

1) Allow in-place expansion of Jar files in the explorer.
2) Allow in-place recognition of versioned systems inside the local
filesystem in the explorer.
3) Prevent modules from creating and using multiple FileObjects over
the same physical resource.
4) Prevent users from adding multiple overlapping filesystems in the
UI (similar to 3).

The current solution is to have a single master filesystem that
aggregates versioned filesystems and archive-based filesystems.
However, there are some drawbacks of this approach, mainly affecting
the ease of use and intuitiveness of the APIs. I find the following
aspects of the current approach unintuitive:

i) When fo.isFolder() returns false, FileUtil.toFile(fo).isDirectory()
may return true. If filesystems API is to be seen as an abstraction
over java.io.File, it should not alter the behavior of Files.

ii) The behavior of file operations is blurred. When I copy a folder
non-recursively (i.e. without its subtree), then the copy is identical
 to the source. What's the semantics of copying x.jar non-recursively
to a new location? Should the copy be identical? If it is identical,
then it contains the subtree!

iii) The following piece of code

FileObject fo1 = ...
FileObject fo2 = fo1.getParent();
File f1 = FileUtil.toFile(fo1);
File f2 = FileUtil.toFile(fo2);
boolean equalFiles = f1.getParentFile().equals(f2);

behaves unintuitively in case that fo1 is a jar entry and fo2 is a jar
file.

iv) The semantics of jar files which are folders is unintuitive for
modules which need to integrate with external tools. It can not be
relied on the filesystem faithfully mirroring the underlying O/S
filesystem.

v) The semantics of the filesystems API can be altered from the
outside, by an external module. It is weird if normally fo.isFolder()
returns false, and then suddenly after installing a new module the
returned value is true.

vi) Practically, modules are not interested in enumerating jar entries
when enumerating the contents of a folder. Thus the auto-mounting has
unnecessary performance implications, as the jar is iterated and then
modules have to filter the iteration.

vii) Similar to iii). The following is unintuitive:

FileObject fo1 = ...
FileObject fo2 = fo1.getParent();
URL u1 = URLMapper.findURL(fo1, URLMapper.INTERNAL);
URL u2 = URLMapper.findURL(fo2, URLMapper.INTERNAL);
boolean starts = u2.startsWith(u2);

In case that that fo1 is a jar entry and fo2 is a jar file,
starts==false, contrary to what one would expect.


Also, the Filesystems API is intended mainly as a non-visual API,
which should not care about the user interface built on top of it. It
is inappropriate to address UI requirements at the level of such an API.

I suggest the following solution to address the individual motivations:

1) Provide a Look for jar/zip files which would display the archive
contents as its subtree.

2) I guess this can continue to be supported by the current mechanism,
although the performance implications of the current solutions are
still quite high, and I am not sure whether this requirement justifies
the performance penalty.

3) I don't think it is possible and practical to "prevent" modules
from creating two FileObjects for a single file. Rather, I would
change this goal to give modules a simple way to access the unique
(preferred) fileobject for a resource. For java.io.File, this is
already possible using method FileUtil.fromFile(File), assuming that
all local files are mounted. For other resources, it could be done as
follows: Provide a static utility method 

FileObject getNestedFileObject(FileObject f),

which, for a given FileObject (e.g. a jar/zip file, but possibly also
a jar URL on a HTTP filesystem), would return the root of the
filesystem that the parameter fileobject represents (e.g. the root of
a JarFileSystem corresponding to the jar file).

4) This can be solved at the UI level in a straightforward way, by not
allowing mounting local, VCS and Jar filesystems (only allowing HTTP
filesystems and other exotic stuff). Or mounting filesystems may not
be necessary at all, depending on the Projects UI decisions.

I have to agree with Petr that the Folder behavior of the zip/jar
files causes lots of problems.
In the Java module we must have explicit check for ".zip/.jar"
extensions to prevent entering into these files (e.g. while finding
package roots).
In my opinion when the FileSystem extensions will be available and the
FileObject will have lookup, the concept of the master filesystem can
be thrown out and replaced by Looks and FS extensions (e.g. VCS can
add Actions and Presentation using decorating look).

One of the most important goals for creating MasterFS was to avoid
mounting filesystems, which users considered confusing. At least
usability studies proved it. FYI motivation for creaeting
MasterFileSystem was writeup and can be found at:
http://core.netbeans.org/proposals/localfs/uview.html#requirements

You mentioned that filesystems API can be considered as an abstraction
over java.io.File. Here I don't agree. Abstraction over java.io.File
is just one implementation called LocalFS and partly also VCSFS. 
Frankly I understand, that current approach may seem not intuitive
enough. With problem described in v) I've ever had mental problem. 
But on the other hand some mentioned asumptions are too free and are
nowhere guaranteed.

I think, that FileSystem extensions won't be designed to replace
arbitrary FileSystem implementation, just will exploit it.  

I hasitate if MasterFileSystem cares about the user interface build on
top of it. 

".zip/.jar" support can be easily disabled by not providing
JarFileSystemProvider impl. Moreover I think, that
JarFileSystemProvider should not be provided neither by openide nor
core, but e.g. by JarPackager. There should be reppraise if there is
need to provide it ever.

Prevent users from adding multiple overlapping filesystems in the
UI is not easy with current API: different implementations of
FileSystems may address the same resources (definitely LoaclFS, VCSFS ). 

I plan to ask for architecture review.  

Thanks for posting the link to the requirements document, it's
interesting.

It looks like we have a slightly different opinion on what is
intuitive and what is not, and what is a big problem vs. a small
problem, and on the details of the solution, but you basically agree
that the current approach has problems, and that the implementation
should be changed in the way so that jar/zip FileObjects on the local
FS are not folders containing zip entries as their children, right?

I do not want to push one particular solution, I am only interested in
getting the problems fixed; I don't much care about the specifics of
the solution. Thanks for your thoughts.

MasterFS won't be part of release 3.6.

The JAR filesystem provider was removed. There was no need for it at
all. In-place expansion of JAR files in the UI works fine without it,
and there are explicit helper methods to get JAR roots when you want them.

Also MasterFS API will be tighten to "automount" only folders and
never files. 

This issue was solved long time ago. Because nobody has reopened it neither
added comments, we are verifying/closing it now. 
If you are still able to reproduce the problem, please reopen. Thanks in advance.