This commit modifies the behavior when setting unsupported attributes to throw an UnsupportedOperationException instead of an IllegalArgumentException. This is to make JimfsFileSystemProvider#createDirectory and JimfsFileSystemProvider#newByteChannel behave consistently with the Javadocs for FileSystemProvider#createDirectory and FileSystemProvider#newByteChannel which require an UnsupportedOperationException to be thrown when the array of attributes contains attributes which can not be set. In particular, these methods are invoked via Files#createDirectory, Files#createTempDirectory and Files#createFile which have the same requirement regarding throwing an UnsupportedOperationException when the array of attributes contains attributes which can not be set. Most notably, this causes a discrepancy between the handling of Jimfs when configured to act like a Windows filesystem versus the behavior of sun.nio.fs.WindowsFileSystem where the former will throw an IllegalArgumentException if an attempt is made to set a POSIX attribute but the latter will throw an UnsupportedOperationException (consistent with the Javadocs).

We use jimfs in the Buck project (https://github.com/facebook/buck/) for a number of our unit tests.

I was fixing some i18n bugs in Buck when I noticed there was no ability to create a filesystem using Turkish normalization rules. This pull request fixes the TODO in PathNormalization and adds a few tests.

I didn't handle regular expression matching yet, since there doesn't seem to be a way to create a Java regular expression using Turkish case-insensitive rules.

I also tidied up a switch statement in Configuration to raise a compiler error if anyone else adds a new enum value to PathNormalization (I was tripped up by this initially since we had a default case which raised a runtime error for new enum values).

Note: I work for Facebook, but we've already signed the Google corporate CLA. I got approval from our Open Source team to send in this pull request.

It looks like there are problems using Jimfs in an environment where user and system code are loaded by separate classloaders. In that case, JimfsFileSystemProvider will be loaded and initialized by the system classloader (because of the META-INF/services entry), while a user who wants to create a file system by calling Jimfs.newFileSystem will be using classes loaded by a different classloader.

The problem is that to create a FileSystem instance, Jimfs calls FileSystems.newFileSystem(...), passing it an environment map containing the Configuration object to be used to configure the file system. When the JimfsFileSystemProvider instance loaded by the system classloader gets this object, it doesn't recognize it as an instance of Configuration, because it was loaded by a different classloader. This leads to an error like:

env map ({config=com.google.common.jimfs.Configuration@15b71125}) must contain key 'config' mapped to an instance of Jimfs.Configuration

Why do we do it this way in the first place? We want to call FileSystems.newFileSystem so that the canonical (system-loaded) JimfsFileSystemProvider instance is used to create (and more importantly, cache) the file system. This is necessary for methods like Paths.get(URI) to work, as it will go to that FileSystemProvider instance and ask it to resolve the URI to a Path. If it doesn't have the FileSystem instance cached, it won't be able to find it and get a Path from it.

Some possible solutions (and the problems with them):

1. Change the environment map that's passed to FileSystems.newFileSystem to only contain standard JDK types. This should solve the classloader issues.
   • Problem: While most of the Configuration object could be converted to a map of standard JDK types, there are a couple things that cannot, specifically the PathType and the set of AttributeProviders the file system should use. It's possible (though it would require changing the API) that we could change the configuration from storing instances of these types to storing only the classes (requiring a default constructor or some such), in which case we could put the names of the classes into the map to be loaded and instantiated by the FileSystemProvider.
   • Even if we did this, though, there are still potential problems if, say, an AttributeProvider deals with attributes whose values are not standard JDK classes--the could be problems when a user tries to set an attribute value on a file and the AttributeProvider doesn't see it as the same class (due to the classloader issues).
2. Stop using FileSystems.newFileSystem to create Jimfs file systems. Use a locally initialized instance of JimfsFileSystemProvider instead. This solves the problem because only the user code classloader should be involved.
   • Problem: It's no longer possible to get a Jimfs Path or FileSystem by its URI using the standard methods in the java.nio.file API. This also prevents things like the recently-added support for Jimfs URLs from working.
3. Try to work around this by making the system-loaded FileSystemProvider for Jimfs not be the real JimfsFileSystemProvider.
   • Rather, it would just be used for caching FileSystem instances as needed for URI-based methods to work.
   • The real JimfsFileSystemProvider would be a singleton, and Jimfs would use that to create a FileSystem instance when Jimfs.newFileSystem is called. It would then pass the created FileSystem itself as a value in the environment map to FileSystems.newFileSystem, allowing the new FileSystem to be cached. Since FileSystem is a JDK type and since the system-loaded FileSystemProvider has no reason to care about any details beyond that, it should have no problem with the FileSystem coming from a different classloader.
   • Since the FileSystemProvider that created the FileSystem will be the one that handles implementing all the methods for it, there should be no issues with the FileSystem functionality.

I think approach 3 should work, but still need to confirm that. It's fairly gross, but should be transparent as long as people are using the API as expected.

In production code I use the static factory methods of nio.file.Paths to create Path objects. The nio.file.Paths utility class uses the default Filesystem.

In my test code I would like to change the default file system, which can be done by setting the system property java.nio.file.spi.DefaultFileSystemProvider. However, in order for this to work, the provider class needs to have a one argument constructor whose formal parameter type is FileSystemProvider. Since JimfsFileSystemProvider doesn't have such a constructor and I can't extend the class (marked as final), I can't make FileSystems.getDefault() return a Jimfs file system.

The WatchService implementation in PollingWatchService uses a hard coded polling frequency (5 seconds). Currently I need to sleep relatively long in my tests in order to receive the event. It would be nice if this could be configured at file system creation time (e.g. by adding something to Configuration.builder()).

Hi all, we are trying to use JimFS as a Virtual File System, using it to create a directory structure, and store Symbolic Links to Files that reside on other File Systems.

We work with very large files and don't have the memory capacity to store these files in memory unfortunately.

Trying to do this, we receive the error "path is not associated with a Jimfs file system" at com.google.common.jimfs.JimfsFileSystemProvider.checkPath(JimfsFileSystemProvider.java:130) at com.google.common.jimfs.JimfsFileSystemProvider.createLink(JimfsFileSystemProvider.java:231) at java.nio.file.Files.createLink(Files.java:1086)

The methods bellow deviate from the default FileSystem implementation in their behaviour to interrupts. If a thread is interrupted when or "while" calling these methods, then the method must throw a ClosedByInterruptException and the channel must be closed:

• FileChannel.position(long)
• FileChannel.position()
• FileChannel.size()
• FileChannel.force(boolean)

There might be other methods that deviate besides these, but these are the ones that my tests caught. Correct interrupt behaviour is important to me, because my code needs to correctly cope with stray interrupts, which I obviously have to test for.

Consider the following code:

try (FileSystem jimFs = Jimfs.newFileSystem(Configuration.unix())) {
	final Path workDir = jimFs.getPath("");
	Files.createFile(workDir.resolve("file1.txt"));
	final Path entry = Files.list(workDir).collect(MoreCollectors.onlyElement());
	LOGGER.info("Entry: {}, abs: {}, exists: {}, exists as abs: {}.", entry, entry.toAbsolutePath(), Files.exists(entry), Files.exists(entry.toAbsolutePath()));
}

It prints: Entry: /file1.txt, abs: /work/file1.txt, exists: false, exists as abs: true.

I think that the entry name /file1.txt is incorrect. This seems to designate an absolute path, whereas a relative path is expected here (relative to the work dir). A bigger problem (maybe caused by the previous one) is that Files.exists reports this entry to not exist. Whereas the same entry is reported to exist when using its absolute form. Whether a file exists should not depend on the form of its path, and this entry does exist, in any case.

Hi there,

I've found a bug in this library.

When using the Files..newOutputStream(path, CREATE, TRUNCATE_EXISTING) method the existing files are not truncated (see the failing unit test in the first commit).

I'd be very happy if you could merge and release this fix, 'cause I have to use some workarounds at the moment.

Thanks, Vilmos

There is no obvious way to convert a URI into a JimfsPath. Normally, one could use fs.provider().getPath(uri), but this is not implemented by JimfsFileSystemProvider; instead, it throws an exception stating:

This method should not be called directly; use Paths.get(URI) instead.

Which is funny, since on #12 @cgdecker (main contributor to the project?)

strongly recommends not using Paths.get

I would've used JimfsFileSystem.toPath(URI), but the entire class is set to the package-private access modifier (why the hell?).

I'm writing a test by emulating a windows file system like so:

Configuration.windows().toBuilder().setRoots("C:\\").build()

The built-in windows configuration has the right settings for case sensitivity:

.setNameCanonicalNormalization(CASE_FOLD_ASCII)
.setPathEqualityUsesCanonicalForm(true) // matches real behavior of WindowsPath

However, the following matcher does not accept files having a TXT extension: fileSystem.getPathMatcher("glob:**.txt")

Looking into the implementation, it seems like the GlobToRegex class should check the actual normalization settings.

Files#readAttributes throws a NullPointerException for a nonexistent attribute view, but according to Javadoc, it should throw an UnsupportedOperationException.

Test case:

public static void main(String... args) throws IOException {
        try (java.nio.file.FileSystem nioFs1 = Jimfs.newFileSystem()) {
            Path test = nioFs1.getPath("test");
            Files.createFile(test);
            Files.readAttributes(test, "nonexistview:*");
        } catch (UnsupportedOperationException unsupported) {
            // expected
        }
    }

Bumps maven-compiler-plugin from 3.8.1 to 3.10.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

The following test case fails for some reason.

  @Test
  void test() throws IOException {
    var blockSize = 1 << 12;
    var configuration = Configuration.unix().toBuilder().setBlockSize(blockSize).build();
    var fs = Jimfs.newFileSystem(configuration);
    var path = fs.getPath("/home/test/test.txt");
    var store = Files.getFileStore(path);
    assertThat(store.getBlockSize()).isEqualTo(blockSize);
  }

I'm explicitly setting the block size, but I get an IOException when the test case is run:

java.lang.UnsupportedOperationException
        at java.base/java.nio.file.FileStore.getBlockSize(FileStore.java:158)
        ...

I would expect the store to return the block size instead.

Any builds on JDK-9 or newer that use modules and have this dependency will currently produce a warning:

Required filename-based automodules detected: [jimfs-1.2.jar]. Please don't publish this project to a public artifact repository!

This should address that issue. For all other purposes this JAR appears to work fine in Java 9 and newer (I am currently using it for a JDK-17-based project).

JimfsFileSystemProvider#getFileSystem(URI) and JimfsFileSystemProvider#getPath(URI) just throw exceptions telling you to use FileSystems.getFileSystem(URI) and Paths.get(URI) respectively, but those recommended methods just fall back on calling these ones that throw unconditional exceptions.

Expectation:

You call Paths.get(URI) where the URI has a jimfs scheme and you get a Path object.

Reality:

You get an exception saying This method should not be called directly; use Paths.get(URI) instead.