| Age | Commit message (Collapse) | Author |
|---|
|
Fixes #85
RELNOTES=n/a
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=278648767
|
|
* Constructors and methods with the same name should appear sequentially with no other code in between. Please re-order or re-name methods.
* Use grouping parenthesis to make the operator precedence explicit
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=274188261
|
|
Configuration's canonical (rather than display) path normalization when the Configuration is set to use canonical normalization for path equality.
This basically affects Windows-like configurations, as Windows/NTFS is the only file system (at least of those Jimfs has a built-in equivalent for) that uses these settings. Essentially, Windows does not normalize the case of file names when displaying paths but it does normalize them (case fold) for comparison and equality. On a real Windows file system, a PathMatcher for "glob:**.txt" or "glob:**.TXT" would match both files ending in ".txt" and files ending in ".TXT".
Fixes https://github.com/google/jimfs/issues/91
RELNOTES=Fixed behavior of `PathMatcher`s for Windows-like configurations to do case-insensitive matching.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=272959573
|
|
- Mostly migrate to Checker Framework declaration annotations.
- Migrate @GuardedBy to a custom annotation for now. (We would migrate to Error Prone's, but that's causing me problems as I experiment with JPMS.)
Compare to b/69411537 for Guava.
I've left @ParametersAreNonnullByDefault in place for now, but we'd need to remove it to fully eliminate the jsr305 dep.
RELNOTES=Migrated from jsr305 `@Nullable` to Checker Framework `@NullableDecl`. In addition to the new dependency on the Checker Framework annotations, we keep the dependency on jsr305 for now so that we can keep using `@ParametersAreNonNullByDefault`.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=272713254
|
|
Fixes https://github.com/google/jimfs/pull/37
RELNOTES=n/a
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=272510710
|
|
its already implemented
Fixes #36
RELNOTES=n/a
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=272432078
|
|
RELNOTES=Run google-java-format over all of JimFS.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=244231542
|
|
RELNOTES=n/a
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=244183449
|
|
the file if the TRUNCATE_EXISTING option was explicitly provided and the WRITE option wasn't.
The code that handles TRUNCATE_EXISTING requires that WRITE also be present for it to do anything (because it's documented that it's ignored otherwise), but newOutputStream should always add the WRITE option if the user doesn't provide it because an OutputStream is obviously for writing. (This matches the default behavior of FileSystemProvider.newOutputStream as well.)
Fixes #77
RELNOTES=Fixed an issue where `Files.newOutputStream` wouldn't truncate the file if the `TRUNCATE_EXISTING` option was explicitly provided and the `WRITE` option wasn't.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=237818016
|
|
configurations have short, meaningful names (e.g. "Configuration{Unix}") while custom instances include the relevant details of the configuration.
Resolves https://github.com/google/jimfs/issues/45
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158857133
|
|
a List) to simply compare the collections' elements.
Eclipse caught this issue, warning "Unlikely argument type for equals():
ImmutableList<Name> seems to be unrelated to Deque<Name>".
Also applied two ErrorProne fixes to "Use grouping parenthesis to make the operator precedence explicit".
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157605901
|
|
environment where ServiceLoader doesn't work correctly to load the SystemJimfsFileSystemProvider.
This is in relation to https://github.com/google/jimfs/issues/31... I don't entirely understand what's going on there, but it does seem like an exception being thrown from FileSystems.newFileSystem should not prevent the user from getting the FileSystem that's already been created just because it can't be cached.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=118790127
|
|
static cache if SystemJimfsFileSystemProvider isn't found in the installed providers list but can be loaded from its ClassLoader by ServiceLoader.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=118472638
|
|
- Throw UOE instead of IAE when attempting to set an attribute that can't be set at all during file creation. This matches the behavior of the real file system implementations.
- Make the owner:owner attribute not settable during file creation, which also matches the actual behavior.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117965277
|
|
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117853112
|
|
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#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).
|
|
- Add @since 1.1 to new public types (though neither of them should be used directly).
- Also @deprecate the required public, no-arg constructors on those types.
- Make SystemJimfsFileSystemProvider final.
- Random whitespace fix.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112710083
|
|
overloads that don't take a Configuration use.
This is primarily for allowing the user to create a modified version of that default configuration, which currently isn't possible without duplicating the logic to get the configuration.
Also remove an unused constant. It's public, but it seems unlikely anyone's using it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112255563
|
|
We've determined that NTFS does not do locale-dependent case mapping (and neither do any other file systems we know of), so providing this option is unnecessary and misleading.
I'm leaving the removal of a TODO I had to consider allowing Turkish-correct case folding and also adding in some notes about the whole situation for posterity.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111990375
|
|
WatchService that Jimfs creates for watching for directory changes.
This is done in such a way that it doesn't make it awkward to create a new WatchService implementation in the future.
Fixes https://github.com/google/jimfs/issues/14.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111885937
|
|
|
|
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=107379017
|
|
Made a bunch of manual fixes, but mostly pretty good.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=94692335
|
|
- tryLock() shouldn't handle interruption.
- lock() should throw FileLockInterruptionException rather than ClosedByInterruptException.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=91829785
|
|
- Update it to handle thread interruption for all methods that handle interruption in the default FileChannel implementation (with the exception of map(), for which we always throw UOE). For most methods that weren't already handling interruption, this mostly just means that if they're called on a thread that's already interrupted they'll throw ClosedByInterruptException and close the channel. Requested in GitHub issue #21. Also add tests for this.
- Make it possible for FileChannel methods that don't use the channel's position (they have a parameter for a specific file position) to proceed concurrently with other FileChannel methods, which is specified as legal in the FileChannel docs: "Other operations, in particular those that take an explicit position, may proceed concurrently".
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=91435386
|
|
a directory.
See this issue: https://github.com/google/jimfs/issues/16
I was initially reluctant to do this because it seems strange to actually access the file system to convert a path to a URI, but this does in fact seem to be the behavior for actual Unix paths. Additionally, when looking into creating a ClassLoader that takes Path objects for the classpath, I noticed that URLClassLoader treats URLs that end with / differently (as directories) from those that don't, which indicates that there are real consequences for not doing this. Note: URLClassLoader is tied to the default file system via File/JarFile by default, so it's not like this change actually enables it to just work with Jimfs files (nor do I have any real reason to think you'd even want to do that, I was just curious).
This involves changing the PathType API to take a boolean parameter indicating whether or not the file is a directory in its method for getting a URI path, which makes this an incompatible change that would probably require a 2.0 release (not that I expect anyone's actually implementing their own PathType).
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=87278575
|
|
Also change usages of base.Objects methods to java.util.Objects where possible.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=87182713
|
|
See https://github.com/google/jimfs/issues/18 for more information.
- SystemJimfsFileSystemProvider (which is loaded as a service by the system classloader) only serves as a cache of FileSystem instances as needed to make Paths.get(URI) work.
- JimfsFileSystemProvider is the actual provider that is returned by JimfsFileSystem.provider(). It is a singleton and provides the real implementation of most of the FileSystemProvider methods, but does not cache FileSystem instances.
We now create the FileSystem instances directly when the user calls Jimfs.newFileSystem rather than passing the Configuration off to FileSystems.newFileSystem. This should ensure no classloader issues when creating the FileSystem. Once created, the FileSystem itself is passed to FileSystems.newFileSystem. There should be no classloader issues here either, since the new SystemJimfsFileSystemProvider implementation does not deal with any other Jimfs-specific classes.
Also add a test that fails without this change.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=87170296
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=86811396
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=86639396
|
|
For URLs to work, Java has to be able to find a URLStreamHandler implementation for the URL protocol/scheme. There isn't any really ideal way to do this programatically, but what this CL does is add "com.google.common" to the "java.protocol.handler.pkgs" system property when JimfsFileSystemProvider is initialized. This means that when Java tries to create a URL with the "jimfs" protocol, it'll look for "jimfs.Handler" under "com.google.common", find it and use it. (Documentation of that behavior found here: http://docs.oracle.com/javase/8/docs/api/java/net/URL.html#URL-java.lang.String-java.lang.String-int-java.lang.String-)
Fixes Github issue #13.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=86627713
|
|
exception when the stream is already already closed.
This matches the behavior of other core OutputStream implementations such as that returned by Files.newOutputStream(Path) for the default FileSystem and prevents an exception when nesting an OutputStream inside a BufferedOutputStream inside an OutputStreamWriter using try-with-resources under JDK8 (among any number of other situations that could cause the same problem).
(Details: try-with-resources closes each declared resource in reverse order. Closing the OutputStreamWriter causes the BufferedOutputStream to be closed which causes the unbuffered OutputStream to be flushed and then closed. Closing the BufferedOutputStream then tries to flush the unbuffered OutputStream again. Prior to JDK8, any exception thrown by this flush() was swallowed and completely ignored; in JDK8, the behavior changed to (correctly) throw that exception.)
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=84439059
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=73318805
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=70269830
|
|
Type inference changes prevent this code from compiling in java 8. In general,
methods that declare type parameters without using them in any formal parameter
declarations should be avoided.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=69903864
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=68905401
|
|
channels, watch services, etc.) and cause almost all other methods to throw ClosedFileSystemException, as per the spec of FileSystem.close(). Does not make Path methods that do not involve the file system itself throw, even if that would technically be the correct thing to do... just doesn't seem worth it to me.
Fixes Github issues #3 and #4.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=67288036
|
|
static map with weak values. To paraphrase the updated Javadoc:
The cache is static to ensure that even when the provider isn't loaded by the system class loader, meaning that a new instance of it must be created each time one of the methods on FileSystems or Paths#get(URI) is called, cached file system instances are still available.
The cache uses weak values so that it doesn't prevent file systems that are created but not closed from being garbage collected if no references to them are held elsewhere. This is a compromise between ensuring that any file URI continues to work as long as the file system hasn't been closed (which is technically the correct thing to do but unlikely to be something that most users care about) and ensuring that users don't get unexpected leaks of large amounts of memory because they're creating many file systems in tests but forgetting to close them (which seems likely to happen sometimes). Users that want to ensure that a file system won't be garbage collected just need to ensure they hold a reference to it somewhere for as long as they need it to stick around.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=66924231
|
|
It's not clear from the Javadoc what exactly it should return, but checking the behavior of the real file system it does appear that usable space should be at most the unallocated space in the store.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=63807322
|
|
(moves/copies to FileSystems with different FileSystemProviders are handled by the Files class itself). Also fix an issue where attributes other than basic attributes were being copied from one file to a file on a different file system when COPY_ATTRIBUTES was specified--there's no guarantee that the other file system will support all the file attribute views the source file system does.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=63161492
|
|
system lock. Otherwise, concurrent copying of files is bottlenecked on the single lock and it's actually faster to copy using streams.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=63093748
|
|
FileChannel/AsychronousFileChannel optional.
Also change JimfsSecureDirectoryStream to check that it's open before each operation as the spec requires and add tests for that.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=60953646
|
|
This means that HeapDisk now uses a RegularFile for its block cache (only using the methods that were on BlockList), but it also saves an additional object per regular file.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=60947141
|
|
package-private UserLookupService.
Users can now only specify default user/group for a file system (in Configuration.Builder) using strings, which seems fine.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=60805963
|
|
they are unlinked.
Instead, when the directory is then linked in a new directory (as in a move), the parent link is overwritten with a new entry. When the directory is deleted, the parent link remains as long as the file object hangs around (as long as a SecureDirectoryStream is open to it, or for the lifetime of the FileSystem if the working directory was deleted.).
This matches the behavior observed running in Linux, the only environment I've tried that supports SecureDirectoryStream.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=60680760
|
|
of File.
While logically it seemed to make sense for the content of each file to be a separate object, it led to awkward code particularly when dealing with directories (since the content needed a reference to the File that contained it) and regular file streams/channels, which needed both a reference to the File and the content anyway.
- ByteStore renamed to RegularFile.
- DirectoryTable renamed to Directory.
- DirectoryEntryMap inlined in to Directory.
- SymbolicLink class added, which just contains a JimfsPath target.
- Various code simplified to accept or return specific File subclasses.
- Also re-add a package-info.java file, mostly just for @ParametersAreNonNullByDefault (for whatever good that does).
This also has the effect of further reducing the number of objects per file in the file system. For example, where a directory was previously a File, DirectoryTable and DirectoryEntryMap, it's now just a Directory.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=60676208
|
|
return value.
|
|
directory
the SDS references has been deleted.
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=60174966
|
|
META-INF/services file.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=60126893
|
