Java windows file system

The default file system, obtained by invoking the FileSystems.getDefault method, provides access to the file system that is accessible to the Java virtual machine. The FileSystems class defines methods to create file systems that provide access to other types of (custom) file systems.

A file system is the factory for several types of objects:

The getPath method converts a system dependent path string, returning a Path object that may be used to locate and access a file.

The getPathMatcher method is used to create a PathMatcher that performs match operations on paths.

The getFileStores method returns an iterator over the underlying file-stores .

The getUserPrincipalLookupService method returns the UserPrincipalLookupService to lookup users or groups by name.

The newWatchService method creates a WatchService that may be used to watch objects for changes and events.

File systems vary greatly. In some cases the file system is a single hierarchy of files with one top-level root directory. In other cases it may have several distinct file hierarchies, each with its own top-level root directory. The getRootDirectories method may be used to iterate over the root directories in the file system. A file system is typically composed of one or more underlying file-stores that provide the storage for the files. Theses file stores can also vary in the features they support, and the file attributes or meta-data that they associate with files.

A file system is open upon creation and can be closed by invoking its close method. Once closed, any further attempt to access objects in the file system cause ClosedFileSystemException to be thrown. File systems created by the default provider cannot be closed.

A FileSystem can provide read-only or read-write access to the file system. Whether or not a file system provides read-only access is established when the FileSystem is created and can be tested by invoking its isReadOnly method. Attempts to write to file stores by means of an object associated with a read-only file system throws ReadOnlyFileSystemException .

File systems are safe for use by multiple concurrent threads. The close method may be invoked at any time to close a file system but whether a file system is asynchronously closeable is provider specific and therefore unspecified. In other words, if a thread is accessing an object in a file system, and another thread invokes the close method then it may require to block until the first operation is complete. Closing a file system causes all open channels, watch services, and other closeable objects associated with the file system to be closed.

Constructor Summary

Constructors

Modifier	Constructor and Description
protected	FileSystem()

Method Summary

Methods

Modifier and Type	Method and Description
abstract void	close()

abstract Path getPath(String first, String. more) abstract PathMatcher getPathMatcher(String syntaxAndPattern) abstract boolean isOpen() abstract boolean isReadOnly()

Methods inherited from class java.lang.Object

Constructor Detail

FileSystem

Method Detail

provider

close

After a file system is closed then all subsequent access to the file system, either by methods defined by this class or on objects associated with this file system, throw ClosedFileSystemException . If the file system is already closed then invoking this method has no effect.

Closing a file system will close all open channels , directory-streams , watch-service , and other closeable objects associated with this file system. The default file system cannot be closed.

isOpen

File systems created by the default provider are always open.

isReadOnly

getSeparator

The name separator is used to separate names in a path string. An implementation may support multiple name separators in which case this method returns an implementation specific default name separator. This separator is used when creating path strings by invoking the toString() method.

In the case of the default provider, this method returns the same separator as File.separator .

getRootDirectories

A file system provides access to a file store that may be composed of a number of distinct file hierarchies, each with its own top-level root directory. Unless denied by the security manager, each element in the returned iterator corresponds to the root directory of a distinct file hierarchy. The order of the elements is not defined. The file hierarchies may change during the lifetime of the Java virtual machine. For example, in some implementations, the insertion of removable media may result in the creation of a new file hierarchy with its own top-level directory.

When a security manager is installed, it is invoked to check access to the each root directory. If denied, the root directory is not returned by the iterator. In the case of the default provider, the SecurityManager.checkRead(String) method is invoked to check read access to each root directory. It is system dependent if the permission checks are done when the iterator is obtained or during iteration.

getFileStores

The elements of the returned iterator are the FileStores for this file system. The order of the elements is not defined and the file stores may change during the lifetime of the Java virtual machine. When an I/O error occurs, perhaps because a file store is not accessible, then it is not returned by the iterator.

In the case of the default provider, and a security manager is installed, the security manager is invoked to check RuntimePermission ("getFileStoreAttributes"). If denied, then no file stores are returned by the iterator. In addition, the security manager’s SecurityManager.checkRead(String) method is invoked to check read access to the file store’s top-most directory. If denied, the file store is not returned by the iterator. It is system dependent if the permission checks are done when the iterator is obtained or during iteration.

Usage Example: Suppose we want to print the space usage for all file stores:

supportedFileAttributeViews

The BasicFileAttributeView is required to be supported and therefore the set contains at least one element, «basic».

The supportsFileAttributeView(String) method may be used to test if an underlying FileStore supports the file attributes identified by a file attribute view.

getPath

The parsing and conversion to a path object is inherently implementation dependent. In the simplest case, the path string is rejected, and InvalidPathException thrown, if the path string contains characters that cannot be converted to characters that are legal to the file store. For example, on UNIX systems, the NUL (\u0000) character is not allowed to be present in a path. An implementation may choose to reject path strings that contain names that are longer than those allowed by any file store, and where an implementation supports a complex path syntax, it may choose to reject path strings that are badly formed.

In the case of the default provider, path strings are parsed based on the definition of paths at the platform or virtual file system level. For example, an operating system may not allow specific characters to be present in a file name, but a specific underlying file store may impose different or additional restrictions on the set of legal characters.

This method throws InvalidPathException when the path string cannot be converted to a path. Where possible, and where applicable, the exception is created with an index value indicating the first position in the path parameter that caused the path string to be rejected.

getPathMatcher

A FileSystem implementation supports the » glob » and » regex » syntaxes, and may support others. The value of the syntax component is compared without regard to case.

When the syntax is » glob » then the String representation of the path is matched using a limited pattern language that resembles regular expressions but with a simpler syntax. For example:

*.java	Matches a path that represents a file name ending in .java
*.*	Matches file names containing a dot
*.	Matches file names ending with .java or .class
foo.?	Matches file names starting with foo. and a single character extension
/home/*/*	Matches /home/gus/data on UNIX platforms
/home/**	Matches /home/gus and /home/gus/data on UNIX platforms
C:\\*	Matches C:\foo and C:\bar on the Windows platform (note that the backslash is escaped; as a string literal in the Java Language the pattern would be "C:\\\\*")

The following rules are used to interpret glob patterns:

The * character matches zero or more characters of a name component without crossing directory boundaries.

The ** characters matches zero or more characters crossing directory boundaries.

The ? character matches exactly one character of a name component.

The backslash character ( \ ) is used to escape characters that would otherwise be interpreted as special characters. The expression \\ matches a single backslash and «\<" matches a left brace for example.

The [ ] characters are a bracket expression that match a single character of a name component out of a set of characters. For example, [abc] matches «a» , «b» , or «c» . The hyphen ( — ) may be used to specify a range so [a-z] specifies a range that matches from «a» to «z» (inclusive). These forms can be mixed so [abce-g] matches «a» , «b» , «c» , «e» , «f» or «g» . If the character after the [ is a ! then it is used for negation so [!a-c] matches any character except «a» , «b» , or «c» .

Within a bracket expression the * , ? and \ characters match themselves. The ( — ) character matches itself if it is the first character within the brackets, or the first character after the ! if negating.

The < >characters are a group of subpatterns, where the group matches if any subpattern in the group matches. The «,» character is used to separate the subpatterns. Groups cannot be nested.

Leading period/dot characters in file name are treated as regular characters in match operations. For example, the «*» glob pattern matches file name «.login» . The Files.isHidden(java.nio.file.Path) method may be used to test whether a file is considered hidden.

All other characters match themselves in an implementation dependent manner. This includes characters representing any name-separators .

The matching of root components is highly implementation-dependent and is not specified.

When the syntax is » regex » then the pattern component is a regular expression as defined by the Pattern class.

For both the glob and regex syntaxes, the matching details, such as whether the matching is case sensitive, are implementation-dependent and therefore not specified.

getUserPrincipalLookupService

Usage Example: Suppose we want to make «joe» the owner of a file:

newWatchService

This method constructs a new watch service that may be used to watch registered objects for changes and events.

• Summary:
• Nested |
• Field |
• Constr |
• Method

• Detail:
• Field |
• Constr |
• Method

Submit a bug or feature
For further API reference and developer documentation, see Java SE Documentation. That documentation contains more detailed, developer-targeted descriptions, with conceptual overviews, definitions of terms, workarounds, and working code examples.
Copyright © 1993, 2020, Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. Also see the documentation redistribution policy.

Java windows file system

The first invocation of any of the methods defined by this class causes the default provider to be loaded. The default provider, identified by the URI scheme «file», creates the FileSystem that provides access to the file systems accessible to the Java virtual machine. If the process of loading or initializing the default provider fails then an unspecified error is thrown.

The first invocation of the installedProviders method, by way of invoking any of the newFileSystem methods defined by this class, locates and loads all installed file system providers. Installed providers are loaded using the service-provider loading facility defined by the ServiceLoader class. Installed providers are loaded using the system class loader. If the system class loader cannot be found then the extension class loader is used; if there is no extension class loader then the bootstrap class loader is used. Providers are typically installed by placing them in a JAR file on the application class path or in the extension directory, the JAR file contains a provider-configuration file named java.nio.file.spi.FileSystemProvider in the resource directory META-INF/services , and the file lists one or more fully-qualified names of concrete subclass of FileSystemProvider that have a zero argument constructor. The ordering that installed providers are located is implementation specific. If a provider is instantiated and its getScheme returns the same URI scheme of a provider that was previously instantiated then the most recently instantiated duplicate is discarded. URI schemes are compared without regard to case. During construction a provider may safely access files associated with the default provider but care needs to be taken to avoid circular loading of other installed providers. If circular loading of installed providers is detected then an unspecified error is thrown.

This class also defines factory methods that allow a ClassLoader to be specified when locating a provider. As with installed providers, the provider classes are identified by placing the provider configuration file in the resource directory META-INF/services .

If a thread initiates the loading of the installed file system providers and another thread invokes a method that also attempts to load the providers then the method will block until the loading completes.

Method Summary

Methods

Modifier and Type	Method and Description
static FileSystem	getDefault()

static FileSystem newFileSystem(Path path, ClassLoader loader) static FileSystem newFileSystem(URI uri, Map env) static FileSystem newFileSystem(URI uri, Map env, ClassLoader loader)

Methods inherited from class java.lang.Object

Method Detail

getDefault

The first invocation of any of the methods defined by this class locates the default provider object. Where the system property java.nio.file.spi.DefaultFileSystemProvider is not defined then the default provider is a system-default provider that is invoked to create the default file system.

If the system property java.nio.file.spi.DefaultFileSystemProvider is defined then it is taken to be a list of one or more fully-qualified names of concrete provider classes identified by the URI scheme «file» . Where the property is a list of more than one name then the names are separated by a comma. Each class is loaded, using the system class loader, and instantiated by invoking a one argument constructor whose formal parameter type is FileSystemProvider . The providers are loaded and instantiated in the order they are listed in the property. If this process fails or a provider’s scheme is not equal to «file» then an unspecified error is thrown. URI schemes are normally compared without regard to case but for the default provider, the scheme is required to be «file» . The first provider class is instantiated by invoking it with a reference to the system-default provider. The second provider class is instantiated by invoking it with a reference to the first provider instance. The third provider class is instantiated by invoking it with a reference to the second instance, and so on. The last provider to be instantiated becomes the default provider; its getFileSystem method is invoked with the URI «file:///» to get a reference to the default file system.

Subsequent invocations of this method return the file system that was returned by the first invocation.

getFileSystem

This method iterates over the installed providers to locate the provider that is identified by the URI scheme of the given URI. URI schemes are compared without regard to case. The exact form of the URI is highly provider dependent. If found, the provider’s getFileSystem method is invoked to obtain a reference to the FileSystem .

Once a file system created by this provider is closed it is provider-dependent if this method returns a reference to the closed file system or throws FileSystemNotFoundException . If the provider allows a new file system to be created with the same URI as a file system it previously created then this method throws the exception if invoked after the file system is closed (and before a new instance is created by the newFileSystem method).

If a security manager is installed then a provider implementation may require to check a permission before returning a reference to an existing file system. In the case of the default file system, no permission check is required.

newFileSystem

This method iterates over the installed providers to locate the provider that is identified by the URI scheme of the given URI. URI schemes are compared without regard to case. The exact form of the URI is highly provider dependent. If found, the provider’s newFileSystem(URI,Map) method is invoked to construct the new file system.

Once a file system is closed it is provider-dependent if the provider allows a new file system to be created with the same URI as a file system it previously created.

Usage Example: Suppose there is a provider identified by the scheme «memory» installed:

newFileSystem

This method first attempts to locate an installed provider in exactly the same manner as the newFileSystem(URI,Map) method. If none of the installed providers support the URI scheme then an attempt is made to locate the provider using the given class loader. If a provider supporting the URI scheme is located then its newFileSystem(URI,Map) is invoked to construct the new file system.

newFileSystem

This method makes use of specialized providers that create pseudo file systems where the contents of one or more files is treated as a file system.

This method iterates over the installed providers. It invokes, in turn, each provider’s newFileSystem(Path,Map) method with an empty map. If a provider returns a file system then the iteration terminates and the file system is returned. If none of the installed providers return a FileSystem then an attempt is made to locate the provider using the given class loader. If a provider returns a file system then the lookup terminates and the file system is returned.

• Summary:
• Nested |
• Field |
• Constr |
• Method

• Detail:
• Field |
• Constr |
• Method

Submit a bug or feature
For further API reference and developer documentation, see Java SE Documentation. That documentation contains more detailed, developer-targeted descriptions, with conceptual overviews, definitions of terms, workarounds, and working code examples.
Copyright © 1993, 2020, Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. Also see the documentation redistribution policy.