Module com.hedera.hashgraph.sdk
Package com.hedera.hashgraph.sdk

Class FileCreateTransaction

java.lang.Object
com.hedera.hashgraph.sdk.Executable<FileCreateTransaction,Transaction,TransactionResponse,TransactionResponse>
com.hedera.hashgraph.sdk.Transaction<FileCreateTransaction>
com.hedera.hashgraph.sdk.FileCreateTransaction
public final class FileCreateTransaction extends Transaction<FileCreateTransaction>
Create a new file. If successful, the new file SHALL contain the (possibly empty) content provided in the `contents` field.
When the current consensus time exceeds the `expirationTime` value, the network SHALL expire the file, and MAY archive the state entry. #### Signature Requirements The HFS manages file authorization in a manner that can be confusing. The core element of file authorization is the `keys` field, which is a `KeyList`; a list of individual `Key` messages, each of which may represent a simple or complex key.
The file service transactions treat this list differently.
A `fileCreate`, `fileAppend`, or `fileUpdate` MUST have a valid signature from _each_ key in the list.
A `fileDelete` MUST have a valid signature from _at least one_ key in the list. This is different, and allows a file "owned" by many entities to be deleted by any one of those entities. A deleted file cannot be restored, so it is important to consider this when assigning keys for a file.
If any of the keys in a `KeyList` are complex, the full requirements of each complex key must be met to count as a "valid signature" for that key. A complex key structure (i.e. a `ThresholdKey`, or `KeyList`, possibly including additional `ThresholdKey` or `KeyList` descendants) may be assigned as the sole entry in a file `keys` field to ensure all transactions have the same signature requirements. If the `keys` field is an empty `KeyList`, then the file SHALL be immutable and the only transaction permitted to modify that file SHALL be a `fileUpdate` transaction with _only_ the `expirationTime` set. #### Shard and Realm The current API ignores shardID and realmID. All files are created in shard 0 and realm 0. Future versions of the API may support multiple realms and multiple shards. ### Block Stream Effects After the file is created, the FileID for it SHALL be returned in the transaction receipt, and SHALL be recorded in the transaction record.