org.vishia.fileRemote

Class FileCluster

java.lang.Object

org.vishia.fileRemote.FileCluster

public class FileCluster
extends java.lang.Object

This class ensures that the same FileRemote instances is used for the same string given path. Different parts of the application can set some attributes in FileRemote, especially masks, it is ensured that all usages get the same instance for the same path. It means also that the properties of a file of the operation system should be read only one time for one Java application. The access to the os file system is reduced. That is usefull especially for a remote file system. But of course synchronizations due to changes of the file system's content is a topic. The operation system's file properties should be synchronized with the FileRemote properties if necessary.
One difference between FileRemote and the operation system's file handling is: FileRemote knows more properties for a file especially mark bits. They should be stored also unique as properties of the file. That is the first reason for this solution.

Nested Class Summary

Nested Classes

Modifier and Type	Class and Description
(package private) class	FileCluster.ListSubdirs

Field Summary

Fields

Modifier and Type	Field and Description
protected java.util.Map<java.lang.String,FileRemote>	idxPaths This index contains the association between paths and its FileRemote instances for all known directories.
static java.lang.String	version Version, history and license.

Constructor Summary

Constructors

Constructor and Description
FileCluster()

Method Summary

Modifier and Type	Method and Description
(package private) FileRemote	getFile(java.lang.CharSequence sDirP, java.lang.CharSequence sName) Gets the existing file instance with this path from the file system or creates and registers a new one.
(package private) FileRemote	getFile(java.lang.CharSequence sDirP1, java.lang.CharSequence sName, boolean assumeChild) Gets the existing file instance with this path from the FileCluster or creates and registers a new one.
private void	idxPathsput(java.lang.String key, FileRemote value)
java.util.Iterator<FileRemote>	listSubdirs(java.lang.String startDir)
private FileRemote	searchOrCreateDir(java.lang.String sPath) Searches a directory due to the given path.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Detail

version

public static final java.lang.String version

Version, history and license.

• 2023-07-15 Hartmut chg: Some errors were obviously caused on non uppercase in windows and non found path from the first level if the FileRemote was also created, but only as child from the root level. fixed.
• 2023-04-02 Hartmut chg: Now uses the TreeMap instead of IndexMultiTable, it's better for debugging. But the functionality have a Iterator for a dedicated range (key start with given string) is not supported by TreeMap. To fulfill it, now the FileCluster.ListSubdirs iterator was built for unchanged listSubdirs(String). But listSubdirs(String) is a little bit changed: It does not need to return a ListIterator, a simple Iterator is sufficient. This simplifies the FileCluster.ListSubdirs.
• 2023-04-02 Hartmut improved: idxPaths contains paths in upper case for windows. There was sometimes irritations, if a directory was given as String in faulty case, was found as file, and was contained twice here. getFile(CharSequence, CharSequence, boolean) and searchOrCreateDir(String) builds upper case for search key.
• 2023-04-02 Hartmut adapted: Because of FileRemote.getPathChars() now returns a '/' on end, but the paths in idxPaths are stored without slash, some adaptions were necessary.
• 2023-04-02 Hartmut cleanup XXXgetFile(...), and XXXcheck(...), that are unused since 2014-12-30
• 2023-02-03 Hartmut chg: not processed but asserted that the given directory for all calls is normalized. This saves unnecessary calculation time, because usual the path is normalized and absolute, because it comes from the cluster itself or proper from the file system.
• 2017-09-15 Hartmut chg: on getFile(CharSequence, CharSequence, boolean): If the file was not found in the index, the new private searchOrCreateDir(String) is invoked instead immediately creating a new FileRemote instance. That routine checks whether the parent is registered and whether the path describes a known FileRemote instance as child of parent. Then that instance is used and registered. Because that routine is invoked recursively, the root will be found. Either that is known, or the root is registered yet, especially on start. For that, all existing FileRemote instances should be re-found, and never a new instance is created though one is exists.
• 2017-08-27 Hartmut chg: On getFile(CharSequence, CharSequence, boolean) only FileFunctions.normalizePath(CharSequence) is invoked. Not FileFunctions.getCanonicalPath(File): Reason: On this access the operation system's file system must not accessed. Only an existing FileRemote instance is searched and returned. Especially if a network directory is accessed and the network is not accessible, this invocation must not hang! It is used in the graphic thread in the org.vishia.commander.
• 2014-12-30 Hartmut chg: Now all parent directories till the root are stored in the table. Therefore the searching algorithm is simplified. Backward search is unnecessary because the parent path is found or it is not stored. Now all as possible directory instances are stored, the tables are greater. The searching is more simple.
• 2014-12-20 Hartmut bugfix: Some files were created more as one with the same path. It were files with lesser pathname which are not found in the idxPaths: fix: Check backward, therefore the IndexMultiTable#iterator(Comparable) is a ListIterator up to now.
• 2013-06-15 Hartmut bugfix: create a FileRemote as directory. It is the convention, that the property whether or not a FileRemote is a directory does not depend on a FileRemote.isTested().
• 2013-05-05 Hartmut chg: get(...) now renamed to getFile(...). getFile(CharSequence, CharSequence, boolean) checks whether a parent instance or deeper child instance is registered already and use that.
• 2013-05-05 Hartmut new: #check(CharSequence, CharSequence)
• 2013-04-22 Hartmut created. The base idea was: Select files and use this selection in another part of application. It should be ensured that the same instance is used for the selection and other usage.

Copyright/Copyleft: For this source the LGPL Lesser General Public License, published by the Free Software Foundation is valid. It means:

1. You can use this source without any restriction for any desired purpose.
2. You can redistribute copies of this source to everybody.
3. Every user of this source, also the user of redistribute copies with or without payment, must accept this license for further using.
4. But the LPGL ist not appropriate for a whole software product, if this source is only a part of them. It means, the user must publish this part of source, but don't need to publish the whole source of the own product.
5. You can study and modify (improve) this source for own using or for redistribution, but you have to license the modified sources likewise under this LGPL Lesser General Public License. You mustn't delete this Copyright/Copyleft inscription in this source file.

If you are intent to use this sources without publishing its usage, you can get a second license subscribing a special contract with the author.

See Also:

Constant Field Values

idxPaths

protected java.util.Map<java.lang.String,FileRemote> idxPaths

This index contains the association between paths and its FileRemote instances for all known directories. It are the used directories in the application, not all of the file system. The files in the directory and also sub directories are contained in FileRemote.children. It is possible that a sub directory is referenced in children, but not registered here. That is if it is itself not used with the content.

Constructor Detail

FileCluster

public FileCluster()

Method Detail

getFile

FileRemote getFile(java.lang.CharSequence sDirP,
                   java.lang.CharSequence sName)

Gets the existing file instance with this path from the file system or creates and registers a new one. If the file is not existing on the file system it is created anyway because the file may be a new candidate.

getFile

FileRemote getFile(java.lang.CharSequence sDirP1,
                   java.lang.CharSequence sName,
                   boolean assumeChild)

Gets the existing file instance with this path from the FileCluster or creates and registers a new one.

If the file is not existing on the file system it is created anyway because the file may be a new candidate. The path is not checked against the file system.

• The file is not registered in the index in this class if it is found as children of a registered directory.
• The parent of the file is created and registered too because the returned file should have a parent.

Parameters:

sDirP - String describes a directory. This string can have backslash instead slash and a non-normalized path (with .. etc. First FileFunctions.normalizePath(CharSequence) will be called with it. It must be an absolute path without environment variable usage, asserted. The absolute path is not build here.

sName - If null then a directory is returned. If given then the returned instance is decided as a file.

assumeChild - true then check whether a requested directory is a child or sub child of a found parent directory. It is possible to create a child without registration here for new files which are not decided as directory firstly.
false then don't assume that the file is a child of a found file. That is only to break a recursion with FileRemote.child(CharSequence) because that method calls this. It creates the FileRemote directory instance in case of not found in the idxPaths.

Returns:

A registered FileRemote instance. It is not tested yet, FileRemote.refreshProperties() may be necessary.

idxPathsput

private void idxPathsput(java.lang.String key,
                         FileRemote value)

searchOrCreateDir

private FileRemote searchOrCreateDir(java.lang.String sPath)

Searches a directory due to the given path. If it is not found, then search the parent and creates the directory as FileRemote from the parent. This is done recursively down till the root. At least the root is created. Either the directory is known, or created yet referred by the parent, at least the root is created yet, especially on start. For that, all existing FileRemote instances should be re-found, and never a new instance is created though one is exists.

Parameters:

sPath - a directory path

Returns:

the existing or new created FileRemote instance.

listSubdirs

public java.util.Iterator<FileRemote> listSubdirs(java.lang.String startDir)