MasterFileSystem

Author: Radek Matous
Changes: available in CVS


MasterFileSystems is implementation of FileSystem that just delegates to the other FileSystem implementations (LocalFileSystem, VCSFileSystem, ...) and playes the role of arbiter that controls  instantiation  and  life cycle of  provided FileObjects.  

Requirements

  1. FileObjects should have exclusive ownership over a resource. Then  just only one FileObject reperesents one java.io.File, then there is ensured, that document opened in editor will be opened only once. This is natural prevention from data lost. 
  2. Simplify access to files. There won't be necessary to mount individual filesystems, because all sources reachable on your computer will be mounted once and automatically.
  3. It's convenient and more natural if path of FileObject corresponds to path of java.io.File (see current strange nbfs protocol).

FileObjects should have exclusive ownership over a resource - in more detail

The most important requirement seems to be and motto for all this effort is: "FileObjects should have exclusive ownership over a resource" that comes form  inceptive issue #25661: There should not be two DataObject for the same java.io.File.

FileSystems gain to NB development is support for change events. Unknown external changes on resources can't be captured by filesystems and are often source of problems because other APIs that depend on filesystems are not notified about changes,
So, we ever recommend to use FileObjects whenever possible. But as a sort of curiosity if there exists two or more instances of FileObject that address the same resource then all changes via one instance of FileObject means external modification for the others, no synchronization among them, no events. This can lead up to loosing data when  there are opened two editors each for one DataObject, both representing the same file which is the problem with the most highest priority. 

There is no easy cure for this problem. Here is suggested TODO list:
  1. classpath can't depend on mounted filesystems in Repository - which is the main cause why to  instantiate overlapping FileSystems
  2. there should exist preferably one reachable instance of  FileSystem for one protocol and also one implementation of FileSystem  should be mostly enough
  3. prevent users of FileSystem impl. from instantiations of FileSystems  (specialized factories should take responsibility for instantiating)  as much as possible
1. In promo-D  there isn't planned to use filesystems for classpath definition anymore. 

2. There was developed special FileSystem called MasterFileSystem that covers request for just one instance of FileSystem for file protocol which is the most important protocol for NetbeansIDE. 

3. Prevent  instantiations of FileSystems means more or less, that  classes that extend  FileSystem shouldn't be publicly accesible.  Everybody should be encouraged to request just resource and some factory should provide it.  URLMapper coul easily take over the role of  factory that should be responsible for  instantiating FileSystems instance for requested protocol. Every implementation of FileSystem should provide its own URLMapper except those that are not intended to stay alone and e.g. are  expected to be just pluged as delegates into MasterFileSystem.


Use cases for providing implementation of MasterFileSystem SPI:

There is no reason for providing more than one implementation of FileSystem related to file protocol.  But we have from historical reasons CVS support  implemented as FileSystem.  MasterFileSystem provides SPI more or less just  because of being able to integrate CVS support and to let it plugin into MasterFileSystem. 
There is no other known use case at the moment and then there is no intention to create a general purpose API,SPI  but rather friend contract (also with respect to performance) between MasterFileSystem and CVS support  implementation (as a metter of evolution currently there public packages: org.netbeans.api.masterfs.*, org.netbeans.spi.masterfs.* which should be probably changed for friend contract). 


Short design view:

Implementation of MasterFileSystem resides in ordirary module OpenIDE-Module: org.netbeans.modules.masterfs.  This module contains also:

  • URLMapper that resolves file protocol and and is responsible for conversion from URL into FileObject and vice versa.

MasterFileSystem  is singleton and isn't publicly accesible.  FileObjects provided by MasterFilesystem are reachable via:
  • URLMapper
  • FileUtil.fromFile
  • Repository - because MasterFileSystem is automaticaly mounted into Repository (defined as instance  in /Mount folder in mf-layer). MasterFileSystem  doesn't keep any persistent information.  But there is intention to remove MasterFileSystem from Repository as soon as conversion utilities FileUtil.toFile, FileUtil.fromfile  use  URLMapper  (just implementation detail).  If there was necessary to visualize  FileObjecs  from MasterFileSystem then the best solution could be to get  all roots  from java.io.File and then find appropriate FileObjects and present them.

FileObjects are created and cached by using not hard Reference.

Every FileObject from MasterFileSystem has at least one delegate which is kept by hard reference but doesn't keep any children.  Delegate is responsible for providing children. Delegate may change during the life of FileObject e.g. delegate from LocalFileSystem can be replaced by delegate from implemenation of some VCS FileSystem. Registered SPI providers can affect which delegate will be used by mounting its own implementation of FileSystem.

FileObjects provided by MasterFileSystem keeps the whole own identity (resource name) and then there is no need to traverse all its parent towards the root to get it.

There is necessary to call refresh to get external changes, fire events and so on.

There is special implementation of root on Windows which has children corresponding to  logical drives (A:, C:, D: ...) ,  has no delegate, there doesn't exist conversion to java.io.File, calling  refresh checks logical drives and fires regular events.  


Status

MasterFileSystem is stable without high priority issues.

Project Features

About this Project

openide was started in November 2009, is owned by Antonin Nebuzelsky, and has 38 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
 
 
Close
loading
Please Confirm
Close