Link abstract interface#

References to filesystem links.

Constructors#

Link() factory#

Creates a Link object.

@pragma("vm:entry-point")
factory Link(String path) {
  final IOOverrides? overrides = IOOverrides.current;
  if (overrides == null) {
    return new _Link(path);
  }
  return overrides.createLink(path);
}

Link.fromRawPath() factory#

@pragma("vm:entry-point")
factory Link.fromRawPath(Uint8List rawPath) {
  // TODO(bkonyi): handle overrides
  return new _Link.fromRawPath(rawPath);
}

Link.fromUri() factory#

Creates a Link object.

If path is a relative path, it will be interpreted relative to the current working directory (see Directory.current), when used.

If path is an absolute path, it will be immune to changes to the current working directory.

factory Link.fromUri(Uri uri) => new Link(uri.toFilePath());

Properties#

absolute no setter override#

A Link instance whose path is the absolute path to this Link.

The absolute path is computed by prefixing a relative path with the current working directory, or returning an absolute path unchanged.

Link get absolute;

hashCode no setter inherited#

The hash code for this object.

A hash code is a single integer which represents the state of the object that affects operator == comparisons.

All objects have hash codes. The default hash code implemented by Object represents only the identity of the object, the same way as the default operator == implementation only considers objects equal if they are identical (see identityHashCode).

If operator == is overridden to use the object state instead, the hash code must also be changed to represent that state, otherwise the object cannot be used in hash based data structures like the default Set and Map implementations.

Hash codes must be the same for objects that are equal to each other according to operator ==. The hash code of an object should only change if the object changes in a way that affects equality. There are no further requirements for the hash codes. They need not be consistent between executions of the same program and there are no distribution guarantees.

Objects that are not equal are allowed to have the same hash code. It is even technically allowed that all instances have the same hash code, but if clashes happen too often, it may reduce the efficiency of hash-based data structures like HashSet or HashMap.

If a subclass overrides hashCode, it should override the operator == operator as well to maintain consistency.

Inherited from Object.

external int get hashCode;

isAbsolute no setter inherited#

Whether this object's path is absolute.

An absolute path is independent of the current working directory (Directory.current). A non-absolute path must be interpreted relative to the current working directory.

On Windows, a path is absolute if it starts with \\ (two backslashes or representing a UNC path) or with a drive letter between a and z (upper or lower case) followed by :\ or :/. This makes, for example, \file.ext a non-absolute path because it depends on the current drive letter.

On non-Windows, a path is absolute if it starts with /.

If the path is not absolute, use absolute to get an entity with an absolute path referencing the same object in the file system, if possible.

Inherited from FileSystemEntity.

bool get isAbsolute => _isAbsolute(path);

parent no setter inherited#

The parent directory of this entity.

Inherited from FileSystemEntity.

Directory get parent => new Directory(parentOf(path));

path no setter inherited#

Inherited from FileSystemEntity.

String get path;

runtimeType no setter inherited#

A representation of the runtime type of the object.

Inherited from Object.

external Type get runtimeType;

uri no setter inherited#

A Uri representing the file system entity's location.

The returned URI's scheme is always "file" if the entity's path is absolute, otherwise the scheme will be empty and the URI relative.

Inherited from FileSystemEntity.

Uri get uri => new Uri.file(path);

Methods#

create()#

Creates a symbolic link in the file system.

The created link will point to the path at target, whether that path exists or not.

Returns a Future that completes with the link when it has been created. If the link path already exists, the future will complete with an error.

If recursive is false, the default, the link is created only if all directories in its path exist. If recursive is true, all non-existing parent paths are created first. The directories in the path of target are not affected, unless they are also in path.

On the Windows platform, this call will create a true symbolic link instead of a junction. Windows treats links to files and links to directories as different and non-interchangable kinds of links. Each link is either a file-link or a directory-link, and the type is chosen when the link is created, and the link then counts as either a file or directory for most purposes. Different Win32 API calls are used to manipulate each. For example, the DeleteFile function is used to delete links to files, and RemoveDirectory must be used to delete links to directories.

The created Windows symbolic link will match the type of the target, if target exists, otherwise a file-link is created. The type of the created link will not change if target is later replaced by something of a different type, but then the link will not be resolvable by resolveSymbolicLinks.

In order to create a symbolic link on Windows, Dart must be run in Administrator mode or the system must have Developer Mode enabled, otherwise a FileSystemException will be raised with ERROR_PRIVILEGE_NOT_HELD set as the errno when this call is made.

On other platforms, the POSIX symlink() call is used to make a symbolic link containing the string target. If target is a relative path, it will be interpreted relative to the directory containing the link.

Future<Link> create(String target, {bool recursive = false});

createSync()#

Creates a symbolic link in the file system.

The created link will point to the path at target, whether that path exists or not.

If the link path already exists, an exception will be thrown.

If recursive is false, the default, the link is created only if all directories in its path exist. If recursive is true, all non-existing parent paths are created first. The directories in the path of target are not affected, unless they are also in path.

On the Windows platform, this call will create a true symbolic link instead of a junction. Windows treats links to files and links to directories as different and non-interchangable kinds of links. Each link is either a file-link or a directory-link, and the type is chosen when the link is created, and the link then counts as either a file or directory for most purposes. Different Win32 API calls are used to manipulate each. For example, the DeleteFile function is used to delete links to files, and RemoveDirectory must be used to delete links to directories.

The created Windows symbolic link will match the type of the target, if target exists, otherwise a file-link is created. The type of the created link will not change if target is later replaced by something of a different type, but then the link will not be resolvable by resolveSymbolicLinks.

In order to create a symbolic link on Windows, Dart must be run in Administrator mode or the system must have Developer Mode enabled, otherwise a FileSystemException will be raised with ERROR_PRIVILEGE_NOT_HELD set as the errno when this call is made.

On other platforms, the POSIX symlink() call is used to make a symbolic link containing the string target. If target is a relative path, it will be interpreted relative to the directory containing the link.

void createSync(String target, {bool recursive = false});

delete() override#

Deletes this Link.

If recursive is false:

• If path corresponds to a link then that path is deleted. Otherwise, delete completes with a FileSystemException.

If recursive is true:

• The FileSystemEntity at path is deleted regardless of type. If path corresponds to a file or link, then that file or link is deleted. If path corresponds to a directory, then it and all sub-directories and files in those directories are deleted. Links are not followed when deleting recursively. Only the link is deleted, not its target. This behavior allows delete to be used to unconditionally delete any file system object.

If this Link cannot be deleted, then delete completes with a FileSystemException.

Future<FileSystemEntity> delete({bool recursive = false});

deleteSync() override#

Synchronously deletes this Link.

If recursive is false:

• If path corresponds to a link then that path is deleted. Otherwise, delete throws a FileSystemException.

If recursive is true:

• The FileSystemEntity at path is deleted regardless of type. If path corresponds to a file or link, then that file or link is deleted. If path corresponds to a directory, then it and all sub-directories and files in those directories are deleted. Links are not followed when deleting recursively. Only the link is deleted, not its target. This behavior allows delete to be used to unconditionally delete any file system object.

If this Link cannot be deleted, then delete throws a FileSystemException.

void deleteSync({bool recursive = false});

exists() inherited#

Checks whether the file system entity with this path exists.

Returns a Future<bool> that completes with the result.

Since FileSystemEntity is abstract, every FileSystemEntity object is actually an instance of one of the subclasses File, Directory, and Link. Calling exists on an instance of one of these subclasses checks whether the object exists in the file system object exists and is of the correct type (file, directory, or link). To check whether a path points to an object on the file system, regardless of the object's type, use the type static method.

Inherited from FileSystemEntity.

Future<bool> exists();

existsSync() inherited#

Synchronously checks whether the file system entity with this path exists.

Since FileSystemEntity is abstract, every FileSystemEntity object is actually an instance of one of the subclasses File, Directory, and Link. Calling existsSync on an instance of one of these subclasses checks whether the object exists in the file system object exists and is of the correct type (file, directory, or link). To check whether a path points to an object on the file system, regardless of the object's type, use the typeSync static method.

Inherited from FileSystemEntity.

bool existsSync();

noSuchMethod() inherited#

Invoked when a nonexistent method or property is accessed.

A dynamic member invocation can attempt to call a member which doesn't exist on the receiving object. Example:

dynamic object = 1;
object.add(42); // Statically allowed, run-time error

This invalid code will invoke the noSuchMethod method of the integer 1 with an Invocation representing the .add(42) call and arguments (which then throws).

Classes can override noSuchMethod to provide custom behavior for such invalid dynamic invocations.

A class with a non-default noSuchMethod invocation can also omit implementations for members of its interface. Example:

class MockList<T> implements List<T> {
  noSuchMethod(Invocation invocation) {
    log(invocation);
    super.noSuchMethod(invocation); // Will throw.
  }
}
void main() {
  MockList().add(42);
}

This code has no compile-time warnings or errors even though the MockList class has no concrete implementation of any of the List interface methods. Calls to List methods are forwarded to noSuchMethod, so this code will log an invocation similar to Invocation.method(#add, [42]) and then throw.

If a value is returned from noSuchMethod, it becomes the result of the original invocation. If the value is not of a type that can be returned by the original invocation, a type error occurs at the invocation.

The default behavior is to throw a NoSuchMethodError.

Inherited from Object.

@pragma("vm:entry-point")
@pragma("wasm:entry-point")
external dynamic noSuchMethod(Invocation invocation);

rename() override#

Renames this link.

Returns a Future that completes with a Link for the renamed link.

If newPath identifies an existing file or link, that entity is removed first. If newPath identifies an existing directory then the future completes with a FileSystemException.

Future<Link> rename(String newPath);

renameSync() override#

Synchronously renames this link.

Returns a Link instance for the renamed link.

If newPath identifies an existing file or link, that entity is removed first. If newPath identifies an existing directory then FileSystemException is thrown.

Link renameSync(String newPath);

resolveSymbolicLinks() override#

Resolves the path of a file system object relative to the current working directory.

Resolves all symbolic links on the path and resolves all .. and . path segments.

resolveSymbolicLinks uses the operating system's native file system API to resolve the path, using the realpath function on Linux and OS X, and the GetFinalPathNameByHandle function on Windows. If the path does not point to an existing file system object, resolveSymbolicLinks throws a FileSystemException.

On Windows the .. segments are resolved before resolving the symbolic link, and on other platforms the symbolic links are resolved to their target before applying a .. that follows.

To ensure the same behavior on all platforms resolve .. segments before calling resolveSymbolicLinks. One way of doing this is with the Uri class:

var path = Uri.parse('.').resolveUri(Uri.file(input)).toFilePath();
if (path == '') path = '.';
var resolved = await File(path).resolveSymbolicLinks();
print(resolved);

since Uri.resolve removes .. segments. This will result in the Windows behavior.

On Windows, attempting to resolve a symbolic link where the link type does not match the type of the resolved file system object will cause the Future to complete with a PathAccessException error.

Future<String> resolveSymbolicLinks();

resolveSymbolicLinksSync() override#

Resolves the path of a file system object relative to the current working directory.

Resolves all symbolic links on the path and resolves all .. and . path segments.

resolveSymbolicLinksSync uses the operating system's native file system API to resolve the path, using the realpath function on linux and OS X, and the GetFinalPathNameByHandle function on Windows. If the path does not point to an existing file system object, resolveSymbolicLinksSync throws a FileSystemException.

On Windows the .. segments are resolved before resolving the symbolic link, and on other platforms the symbolic links are resolved to their target before applying a .. that follows.

To ensure the same behavior on all platforms resolve .. segments before calling resolveSymbolicLinksSync. One way of doing this is with the Uri class:

var path = Uri.parse('.').resolveUri(Uri.file(input)).toFilePath();
if (path == '') path = '.';
var resolved = File(path).resolveSymbolicLinksSync();
print(resolved);

since Uri.resolve removes .. segments. This will result in the Windows behavior.

On Windows, a symbolic link is created as either a file link or a directory link. Attempting to resolve such a symbolic link requires the link type to match the type of the file system object that it points to, otherwise it throws a PathAccessException.

String resolveSymbolicLinksSync();

stat() inherited#

Calls the operating system's stat() function on path.

Identical to FileStat.stat(this.path).

Returns a Future<FileStat> object containing the data returned by stat().

If path is a symbolic link then it is resolved and results for the resulting file are returned.

If the call fails, completes the future with a FileStat object with .type set to FileSystemEntityType.notFound and the other fields invalid.

Inherited from FileSystemEntity.

Future<FileStat> stat() => FileStat.stat(path);

statSync() inherited#

Synchronously calls the operating system's stat() function on path.

Identical to FileStat.statSync(this.path).

Returns a FileStat object containing the data returned by stat().

If path is a symbolic link then it is resolved and results for the resulting file are returned.

If the call fails, returns a FileStat object with .type set to FileSystemEntityType.notFound and the other fields invalid.

Inherited from FileSystemEntity.

FileStat statSync() => FileStat.statSync(path);

target()#

Gets the target of the link.

Returns a future that completes with the path to the target.

If the returned target is a relative path, it is relative to the directory containing the link.

If the link does not exist, or is not a link, the future completes with a FileSystemException.

Future<String> target();

targetSync()#

Synchronously gets the target of the link.

Returns the path to the target.

If the returned target is a relative path, it is relative to the directory containing the link.

If the link does not exist, or is not a link, throws a FileSystemException.

String targetSync();

toString() inherited#

A string representation of this object.

Some classes have a default textual representation, often paired with a static parse function (like int.parse). These classes will provide the textual representation as their string representation.

Other classes have no meaningful textual representation that a program will care about. Such classes will typically override toString to provide useful information when inspecting the object, mainly for debugging or logging.

Inherited from Object.

external String toString();

update()#

Updates an existing link.

Deletes the existing link at path and creates a new link to target, using create.

Returns a future which completes with this Link if successful, and with a PathNotFoundException if there is no existing link at path, or with any FileSystemException that delete or create can throw.

Future<Link> update(String target);

updateSync()#

Synchronously updates an existing link.

Deletes the existing link at path and uses createSync to create a new link to target. Throws PathNotFoundException if the original link does not exist or any FileSystemException that deleteSync or createSync can throw.

void updateSync(String target);

watch() inherited#

Start watching the FileSystemEntity for changes.

The implementation uses platform-dependent event-based APIs for receiving file-system notifications, thus behavior depends on the platform.

• Windows: Uses ReadDirectoryChangesW. The implementation only supports watching directories. Recursive watching is supported.

• Linux: Uses inotify. The implementation supports watching both files and directories. Recursive watching is not supported. Note: When watching files directly, delete events might not happen as expected.

• OS X: Uses the File System Events API. The implementation supports watching both files and directories. Recursive watching is supported. This API has several limitations:

  • Changes that occurred shortly before the watch method was called may still appear in the Stream.
  • Changes that occur in a short period of time may arrive out-of-order.
  • Multiple changes made in a single directory may be coalesced into a single FileSystemEvent.

The system will start listening for events once the returned Stream is being listened to, not when the call to watch is issued.

The returned value is an endless broadcast Stream, that only stops when one of the following happens:

• The Stream is canceled, e.g. by calling cancel on the StreamSubscription.
• The FileSystemEntity being watched is deleted.
• System Watcher exits unexpectedly. e.g. On Windows this happens when buffer that receive events from ReadDirectoryChangesW overflows.

Use events to specify what events to listen for. The constants in FileSystemEvent can be or'ed together to mix events. Default is FileSystemEvent.all.

A move event may be reported as separate delete and create events.

Inherited from FileSystemEntity.

Stream<FileSystemEvent> watch({
  int events = FileSystemEvent.all,
  bool recursive = false,
}) {
  &#47;&#47; FIXME(bkonyi): find a way to do this using the raw path.
  final String trimmedPath = _trimTrailingPathSeparators(path);
  final IOOverrides? overrides = IOOverrides.current;
  if (overrides == null) {
    return _FileSystemWatcher._watch(trimmedPath, events, recursive);
  }
  return overrides.fsWatch(trimmedPath, events, recursive);
}

Operators#

operator ==() inherited#

The equality operator.

The default behavior for all Objects is to return true if and only if this object and other are the same object.

Override this method to specify a different equality relation on a class. The overriding method must still be an equivalence relation. That is, it must be:

• Total: It must return a boolean for all arguments. It should never throw.

• Reflexive: For all objects o, o == o must be true.

• Symmetric: For all objects o1 and o2, o1 == o2 and o2 == o1 must either both be true, or both be false.

• Transitive: For all objects o1, o2, and o3, if o1 == o2 and o2 == o3 are true, then o1 == o3 must be true.

The method should also be consistent over time, so whether two objects are equal should only change if at least one of the objects was modified.

If a subclass overrides the equality operator, it should override the hashCode method as well to maintain consistency.

Inherited from Object.

external bool operator ==(Object other);