Gets the raw byte contents of this file without implicit synchronization.

See SakerFile.getBytes().

Gets the content descriptor of this file.

See ContentDescriptor. Content descriptors are used to determine if the file contents need to be persisted to the file system.

Subclasses should note that if they use posix file permissions then they should return a content descriptor that reflects this behaviour. They are recommended to use PosixFilePermissionsDelegateContentDescriptor to construct the actual content descriptor.

Gets the string contents of this file without implicit synchronization.

See SakerFile.getContent().

Gets the efficient opening methods flag of this file.

An opening method is considered (performance-wise) efficient if it generally takes less resources (time and memory) to call the appropriate content method instead of trying to employ caching to the disk.

If an opening method is reported as efficient, then the implicit synchronizations will not take place specified by the documentation of SakerFile interface.

If an opening method is not reported as efficient, then calling content retrieval methods which do not end with Impl will check if the file system already has the contents of this file persisted, and will read the contents from there if it has. If not, then the contents will be synchronized with to the disk, and the contents will be retrieved in the most efficient manner. (This manner depends on the nature of the opening method.)

The default implementation returns SakerFile.OPENING_METHODS_NONE.

Gets the posix file permissions that are associated with this file.

This method returns the set of posix file permissions that were associated with the given file as part of the build execution.

Subclasses can override this method to explicitly set the permissions, however, if they do so then they also need to return a content descriptor that reflects this association. They are encouraged to use PosixFilePermissionsDelegateContentDescriptor to construct the actual content descriptor if posix file permissions are set for a file.

Subclasses that return non-null from this method are also required to set these permissions in the synchronization methods.

Note that this method will return null by default even when the build is running on file systems that support posix file permissions. The posix file permissions are not automatically queried by the build system but only if a build execution previously set it.

Opens a byte source to the contents of this file without implicit synchronization.

See SakerFile.openByteSource().

If subclasses override this method, they must override SakerFile.openInputStreamImpl() as well. (Simply returning ByteSource.toInputStream(openByteSourceImpl()) is fine.)

Opens an input stream to the contents of this file without implicit synchronization.

See SakerFile.openInputStream().

Synchronizing implementation for persisting the contents of this file to the target file system location.

This method will not check if the contents of the disk have been changes in relation to this file, but will always persist it to the given location.

Subclasses should implement this method to persist its contents to the location specified by the parameter.

If subclasses override this method, they must override SakerFile.synchronizeImpl(ProviderHolderPathKey, ByteSink) as well. (They can just simply call SakerFile.synchronizeImpl(ProviderHolderPathKey) and return false.)

Subclasses should set any posix file permissions there are associated with the file during synchronization.

Overloaded synchronizing method with additional output stream to write the contents to.

This method will not check if the contents of the disk have been changes in relation to this file, but will always persist it to the given location.

This method exists for performance optimization. Subclasses should override this method and attempt to concurrently persist the contents of the file to the target location and write the contents to the additional stream.

Subclasses must not throw an IOException if the writing to the additional stream failed, but rethrow them as a SecondaryStreamException. If a SecondaryStreamException is thrown, the synchronization is going to be considered as successful, and only the writing to the secondary stream is considered as failure. If an IOException is thrown, both stream writings is considered to be failed.

The implementations are not required to handle concurrent writing. This method should return true if it was able to concurrently synchronize and write the contents to the additional stream. The PriorityMultiplexOutputStream utility class can help implementations in implementing this functionality.

Overriding this method will improve the overall synchronization performance.

If subclasses override this method, they must override SakerFile.synchronizeImpl(ProviderHolderPathKey) as well.

Subclasses should set any posix file permissions there are associated with the file during synchronization.

Writes the contents of this file without implicit synchronization.

See SakerFile.writeTo(OutputStream).

To call this method using a ByteSink, use ByteSink.toOutputStream(ByteSink) to create a delegate object.

Implementations can use ByteSink.valueOf(OutputStream) to convert the argument to a byte sink if required.