class WireWeakSyncClientImpl

Acquires an advisory lock on the underlying file.

The lock lasts until either this connection is closed or

this method is called with |AdvisoryLockType.UNLOCK| to release the lock

explicitly.

Advisory locks are purely advisory. They do not prevent actual read or

write operations from occurring on the file, either through this

connection or through other connections.

This method requires the following rights:

* [`Rights.READ_BYTES`] if `request.type` is [`AdvisoryLockType.READ`].

* [`Rights.WRITE_BYTES`] if `request.type` is

[`AdvisoryLockType.WRITE`].

# Errors

* `ZX_ERR_BAD_STATE` The specified type of lock cannot be acquired. For

example, another connection might hold a conflicting lock type.

* `ZX_ERR_NOT_SUPPORTED` This file does not support advisory locking.

* `ZX_ERR_ACCESS_DENIED` This connection does not have sufficient rights

to acquire the given type of lock.

Allocates 112 bytes of message buffer on the stack. No heap allocation necessary.

Creates a link to this this object with name `dst` in the directory represented by

`dst_parent_token`.

`dst` must be a resolved object name. Including "/" in the string will return

`ZX_ERR_INVALID_ARGS`.

This method requires the maximal set of rights supported by the filesystem for this object.

For files this would typically be [`Rights.READ_BYTES`], [`Rights.WRITE_BYTES`],

[`Rights.GET_ATTRIBUTES`] and [`Rights.UPDATE_ATTRIBUTES`]. Some filesystems might also

support the [`Rights.EXECUTE`] right. Insufficient rights will result in

`ZX_ERR_ACCESS_DENIED`.

If this object has no links and is *NOT* an unnamed temporary object (objects opened with

`Flags.FLAG_CREATE_AS_UNNAMED_TEMPORARY`), it will fail with `ZX_ERR_NOT_FOUND`.

For unnamed temporary objects, use LinkInto to give it a name. Upon successful completion,

the object will be permanently linked to the filesystem. Requires that the unnamed temporary

object is linkable, if not, it will fail with `ZX_ERR_NOT_FOUND`.

This method does not have the same atomicity properties has the `Directory::Link` method,

which means that calling `Open` then `LinkInto` is not equivalent to `Directory::Link`

because `LinkInto` will not prevent the source from being renamed or unlinked.

Allocates 328 bytes of message buffer on the stack. No heap allocation necessary.

Terminates the connection.

After calling `Close`, the client must not send any other requests.

Servers, after sending the status response, should close the connection

regardless of status and without sending an epitaph.

Closing the client end of the channel should be semantically equivalent

to calling `Close` without knowing when the close has completed or its

status.

Allocates 48 bytes of message buffer on the stack. No heap allocation necessary.

Allocates 16 bytes of request buffer on the stack. Response is heap-allocated.

DEPRECATED - Use `Node.GetAttributes` instead.

Allocates 96 bytes of message buffer on the stack. No heap allocation necessary.

DEPRECATED - Use `Node.UpdateAttributes` instead.

Allocates 104 bytes of message buffer on the stack. No heap allocation necessary.

[DEPRECATED - Use new GetFlags method instead.]

Allocates 40 bytes of message buffer on the stack. No heap allocation necessary.

[DEPRECATED - Use new SetFlags method instead.]

Allocates 48 bytes of message buffer on the stack. No heap allocation necessary.

Queries the flags that apply to this node after it has been opened/created. This method does

not require any rights.

Note that the final set of flags that apply to the connection may differ from those

specified with the `fuchsia.io/Directory.Open` request used to create it:

- `Flags.PERM_INHERIT_*`: Only applies when determining connection rights.

- `Flags.PROTOCOL_*`: Only the protocol of the connection will be present.

- `Flags.FLAG_*`: Only applies when opening the resource, not part of the connection.

Allocates 56 bytes of message buffer on the stack. No heap allocation necessary.

Sets the flags that apply to this node after it has been opened. This method does not

require any rights.

Only `Flags.FILE_APPEND` is currently supported. Calling this method without any flags will

clear append mode.

Errors:

- `ZX_ERR_NOT_SUPPORTED`: The object does not support this feature or the specified flags.

- `ZX_ERR_INVALID_ARGS`: `flags` other than `Flags.FILE_APPEND` were specified.

Allocates 56 bytes of message buffer on the stack. No heap allocation necessary.

Query the filesystem for details specific to the filesystem and/or volume. If the current

volume has different settings or the storage is accounted seperately from the rest of the

filesystem that may be reported instead of filesystem-wide details.

Allocates 144 bytes of message buffer on the stack. No heap allocation necessary.

Acquires information about the node.

The attributes of a node should be stable, independent of the

specific protocol used to access it.

If a particular attribute is not applicable or not supported,

filesystems should leave the corresponding field absent.

+ `query` a bit-mask specifying which attributes to fetch. The server

should not return more than necessary.

- `attributes` the returned attributes.

This method requires the [`Rights.GET_ATTRIBUTES`] right.

Allocates 24 bytes of request buffer on the stack. Response is heap-allocated.

Updates information about the node.

+ `attributes` the presence of a table field in `attributes` indicates

the intent to update the corresponding attribute.

Returns `ZX_ERR_NOT_SUPPORTED` if the node does not support any of the specified attributes.

This method requires the [`Rights.UPDATE_ATTRIBUTES`] right.

Allocates 480 bytes of message buffer on the stack. No heap allocation necessary.

Synchronizes updates to the node to the underlying media, if it exists.

This method will return when the filesystem server has flushed the

relevant updates to the underlying media, but does not guarantee the

underlying media has persisted the information, nor that any information

is committed to hardware. Clients may use `Sync` to ensure ordering

between operations.

This method does not require any rights.

Allocates 48 bytes of message buffer on the stack. No heap allocation necessary.

Get the value associated with the given attribute `name` for this node.

Attribute names have a maximum length of MAX_ATTRIBUTE_NAME. No

particular structure is imposed on them.

This method requires the [`Rights.GET_ATTRIBUTES`] right.

Allocates 288 bytes of request buffer on the stack. Response is heap-allocated.

Set the value for the given attribute `name` to `value` for this node.

The attribute name may exist, in which case the attribute is updated.

If the attribute doesn't exist, it is created. The name should have no

null bytes in it. If it does, ZX_ERR_INVALID_ARGS is returned.

This method requires the [`Rights.UPDATE_ATTRIBUTES`] right.

Allocates 32 bytes of response buffer on the stack. Request is heap-allocated.

Remove the specified extended attribute.

If the attribute doesn't exist, ZX_ERR_NOT_FOUND is returned.

This method requires the [`Rights.UPDATE_ATTRIBUTES`] right.

Allocates 320 bytes of message buffer on the stack. No heap allocation necessary.

Reads up to 'count' bytes at the seek offset.

The seek offset is moved forward by the number of bytes read.

## Invariants

* The returned `data.length` will never be greater than `count`.

* If `data.length` is less than `count`, it means that the seek offset

has reached the end of file as part of this operation.

* If `data.length` is zero while `count` is not, it means that the

seek offset is already at or beyond the end of file, and no data could

be read.

* If `count` is zero, the server should perform all the checks ensuring

read access without actually read anything, and return an empty

`data` vector.

This method requires the [`Rights.READ_BYTES`] right.

Returns `ZX_ERR_OUT_OF_RANGE` if `count` is greater than `MAX_TRANSFER_SIZE`.

Allocates 24 bytes of request buffer on the stack. Response is heap-allocated.

Writes data at the seek offset.

The seek offset is moved forward by the number of bytes written.

If the file is in append mode, the seek offset is first set to the end

of the file, followed by the write, in one atomic step.

The file size may grow if the seek offset plus `data.length` is beyond

the current end of file.

+ request `data` the byte buffer to write to the file.

- response `actual_count` the number of bytes written.

## Invariants

* The returned `actual_count` will never be greater than `data.length`.

* If the server is unable to write all the data due to e.g. not enough

space, `actual_count` may be less than `data.length`. If no bytes

could be written, an error is returned.

* If `data.length` is zero, the server should perform all the checks

ensuring write access without mutating the file and return a

successful write of zero bytes. The seek offset is still updated if

in append mode.

This method requires the [`Rights.WRITE_BYTES`] right.

Allocates 40 bytes of response buffer on the stack. Request is heap-allocated.

Allocates 16 bytes of request buffer on the stack. Response is heap-allocated.

Moves the offset at which the next invocation of [`Read`] or [`Write`]

will occur. The seek offset is specific to each file connection.

+ request `origin` the reference point where `offset` will be based on.

+ request `offset` the number of bytes to seek.

- response `offset_from_start` the adjusted seek offset, from the start

of the file.

This method does not require any rights.

Allocates 72 bytes of message buffer on the stack. No heap allocation necessary.

Reads up to 'count' bytes at the provided offset.

Does not affect the seek offset.

## Invariants

* The returned `data.length` will never be greater than `count`.

* If `data.length` is less than `count`, it means that `ReadAt` has hit

the end of file as part of this operation.

* If `data.length` is zero while `count` is not, it means that `offset`

is at or past the end of file, and no data can be read.

* If `count` is zero, the server should perform all the checks ensuring

read access without actually reading anything, and return an empty

`data` vector.

This method requires the [`Rights.READ_BYTES`] right.

Returns `ZX_ERR_OUT_OF_RANGE` if `count` is greater than `MAX_TRANSFER_SIZE`.

Allocates 32 bytes of request buffer on the stack. Response is heap-allocated.

Writes data at the provided offset.

Does not affect the seek offset.

The file size may grow if `offset` plus `data.length` is past the

current end of file.

+ request `data` the byte buffer to write to the file.

+ request `offset` the offset from start of the file to begin writing.

- response `actual_count` the number of bytes written.

## Invariants

* The returned `actual_count` will never be greater than `data.length`.

* If the server is unable to write all the data due to e.g. not enough

space, `actual_count` may be less than `data.length`. If no bytes

could be written, an error is returned.

* If `data.length` is zero, the server should perform all the checks

ensuring write access without mutating the file, and will return a

successful write of zero bytes.

This method requires the [`Rights.WRITE_BYTES`] right.

Allocates 40 bytes of response buffer on the stack. Request is heap-allocated.

Shrinks or grows the file size to 'length' bytes.

If file size is reduced by this operation, the extra trailing data'

is discarded.

If file size is increased by this operation, the extended area appears

as if it was zeroed.

This method requires the [`Rights.WRITE_BYTES`] right.

Allocates 56 bytes of message buffer on the stack. No heap allocation necessary.

Acquires a [`zx.Handle:VMO`] representing this file, if there is one,

with the requested access rights.

Implementations are not required to implement files backed by VMOs so

this request may fail. Additionally, implementations may only support

a certain subset of the flags. Clients should be prepared with fallback

behavior if this request fails.

If a client specifies neither `PRIVATE_CLONE` nor `SHARED_BUFFER`, the

implementation is free to choose the semantics of the returned VMO.

+ request `flags` a [`VmoFlags`] indicating the desired mode of access.

- response `vmo` the requested [`zx.Handle:VMO`].

* error a [`zx.Status`] value indicating the failure.

This method requires the following rights:

* [`Rights.READ_BYTES`] if `flags` includes [`VmoFlags.READ`].

* [`Rights.WRITE_BYTES`] if `flags` includes [`VmoFlags.WRITE`].

* [`Rights.EXECUTE`] if `flags` includes [`VmoFlags.EXECUTE`].

Allocates 56 bytes of message buffer on the stack. No heap allocation necessary.

Pre-allocate on-disk space for this file.

Allocates 72 bytes of message buffer on the stack. No heap allocation necessary.

Enables verification for the file (permanently) which involves computing a merkle tree for

the file. Forces a flush prior to building the merkle tree to ensure cached data is

captured. Future reads will be verified against the computed merkle tree and writes will be

rejected. This method can take some time to complete as it depends on the size of the file.

This method can be aborted by closing the connection that this method was issued on.

This method requires the [`Rights.UPDATE_ATTRIBUTES`] right.

Returns `ZX_ERR_NOT_SUPPORTED` if the filesystem does not support verity.

Returns `ZX_ERR_ALREADY_EXISTS` if the file was already fsverity-enabled.

Also returns any error that might arise from reading the file, or from flushing the file,

such as `ZX_ERR_IO`.

Allocates 128 bytes of message buffer on the stack. No heap allocation necessary.