Request: implement all `Files` methods in `FasterFiles` (even if directly calling the `Files` implementation)

[sschr15]

Remembering if FasterFiles contains a particular function is a bit of a challenge, so re-implementing all Files methods in it would be convenient and could also provide a way of identifying future possible improvements to faster filesystems.

[AlexIIL]

re-implementing all Files methods in it would be convenient

Yes, and that's actually a good enough reason to implement them.

identifying future possible improvements to faster filesystems.

Not really, due to how limited FasterFiles is meant to be - it optimizes methods by skipping any unnecessary work and letting the FileSystem decide how best to implement it.

For example Files.isDirectory does this:

public static boolean isDirectory(Path path, LinkOption... options) {
    try {
        return readAttributes(path, BasicFileAttributes.class, options).isDirectory();
    } catch (IOException ioe) {
        return false;
    }
}

Not only is reading attributes potentially expensive, it also needs to throw an IOException if a file wasn't found - which (for an in memory file system based on Map<Path, Thing>) is much more expensive than just Map<Path, QuiltMemoryEntry> . get(path) instanceof QuiltMemoryFolder.

However for a method like Files.newInputStream, it does this:

public static InputStream newInputStream(Path path, OpenOption... options)
    throws IOException
{
    return path.getFileSystem().provider().newInputStream(path, options);
}

Since it (pretty much) directly calls FileSystem.newInputStream anyway, there's not much to be gained by skipping the provider() call (which is basically what all FasterFiles methods boil down to - just getting the paths FileSystem, then checking if it's an instanceof FasterFileSystem, then calling the appropriate method).