Files in UCloud is a resource for storing, retrieving and organizing data in UCloud.
Rationale
📝 NOTE: This API follows the standard Resources API. We recommend that you have already read and understood the concepts described here.
The file-system of UCloud provide researchers with a way of storing large data-sets efficiently and securely. The file-system is one of UCloud's core features and almost all other features, either directly or indirectly, interact with it. For example:
All interactions in UCloud (including files) are automatically audited
UCloud allows compute Jobs to consume UCloud files. Either through containerized workloads or virtual machines.
A file in UCloud (UFile) closely follows the concept of a computer file you might already be familiar with. The functionality of a file is mostly determined by its type. The two most important types are the DIRECTORY and FILE types. A DIRECTORY is a container of UFiles. A directory can itself contain more directories, which leads to a natural tree-like structure. FILEs, also referred to as a regular files, are data records which each contain a series of bytes.
📝 Provider Note: This is the API exposed to end-users. See the table below for other relevant APIs.
# ------------------------------------------------------------------------------------------------------# $host is the UCloud instance to contact. Example: 'http://localhost:8080' or 'https://cloud.sdu.dk'# $accessToken is a valid access-token issued by UCloud# ------------------------------------------------------------------------------------------------------# Authenticated as usercurl -XPOST -H "Authorization: Bearer $accessToken" -H "Content-Type: content-type: application/json; charset=utf-8" "$host/api/files/copy" -d '{
"items": [ {"oldId":"/123/my/file","newId":"/123/my/file","conflictPolicy":"RENAME" } ]}'# {# "responses": [# {# "type": "complete"# }# ]# }
Communication Flow: Visual
Example: Uploading a file
Frequency of use
Common
Trigger
User initiated
Pre-conditions
A folder at '/123/folder'
The user has EDIT permissions on the file
The provider supports the CHUNKED protocol
Post-conditions
A new file present at '/123/folder/file'
Actors
An authenticated user (user)
Communication Flow: Kotlin
Files.createUpload.call(bulkRequestOf(FilesCreateUploadRequestItem( conflictPolicy = WriteConflictPolicy.REJECT, id ="/123/folder", supportedProtocols =listOf(UploadProtocol.CHUNKED), )), user).orThrow()/*BulkResponse( responses = listOf(FilesCreateUploadResponseItem( endpoint = "https://provider.example.com/ucloud/example-provider/chunked", protocol = UploadProtocol.CHUNKED, token = "f1460d47e583653f7723204e5ff3f50bad91a658", )), )*//* The user can now proceed to upload using the chunked protocol at the provided endpoint */
Communication Flow: Curl
# ------------------------------------------------------------------------------------------------------# $host is the UCloud instance to contact. Example: 'http://localhost:8080' or 'https://cloud.sdu.dk'# $accessToken is a valid access-token issued by UCloud# ------------------------------------------------------------------------------------------------------# Authenticated as usercurl -XPOST -H "Authorization: Bearer $accessToken" -H "Content-Type: content-type: application/json; charset=utf-8" "$host/api/files/upload" -d '{
"items": [ {"id":"/123/folder","supportedProtocols": ["CHUNKED" ],"conflictPolicy":"REJECT" } ]}'# {# "responses": [# {# "endpoint": "https://provider.example.com/ucloud/example-provider/chunked",# "protocol": "CHUNKED",# "token": "f1460d47e583653f7723204e5ff3f50bad91a658"# }# ]# }# The user can now proceed to upload using the chunked protocol at the provided endpoint
Communication Flow: Visual
Example: Downloading a file
Frequency of use
Common
Trigger
User initiated
Pre-conditions
A file at '/123/folder/file
The user has READ permissions on the file
Actors
An authenticated user (user)
Communication Flow: Kotlin
Files.createDownload.call(bulkRequestOf(FilesCreateDownloadRequestItem( id ="/123/folder/file", )), user).orThrow()/*BulkResponse( responses = listOf(FilesCreateDownloadResponseItem( endpoint = "https://provider.example.com/ucloud/example-provider/download?token=d293435e94734c91394f17bb56268d3161c7f069",
)), )*//* The user can now download the file through normal HTTP(s) GET at the provided endpoint */
Communication Flow: Curl
# ------------------------------------------------------------------------------------------------------# $host is the UCloud instance to contact. Example: 'http://localhost:8080' or 'https://cloud.sdu.dk'# $accessToken is a valid access-token issued by UCloud# ------------------------------------------------------------------------------------------------------# Authenticated as usercurl -XPOST -H "Authorization: Bearer $accessToken" -H "Content-Type: content-type: application/json; charset=utf-8" "$host/api/files/download" -d '{
"items": [ {"id":"/123/folder/file" } ]}'# {# "responses": [# {# "endpoint": "https://provider.example.com/ucloud/example-provider/download?token=d293435e94734c91394f17bb56268d3161c7f069"
# }# ]# }# The user can now download the file through normal HTTP(s) GET at the provided endpoint
The results will be returned using the standard pagination API of UCloud. Consistency is slightly relaxed for this endpoint as it is typically hard to enforce for filesystems. Provider's are heavily encouraged to try and find all files on the first request and return information about them in subsequent requests. For example, a client might list all file names in the initial request and use this list for all subsequent requests and retrieve additional information about the files. If the files no longer exist then the provider should simply not include these results.
This file can be of any type. Clients can request additional information about the file using the include* flags of the request. Note that not all providers support all information. Clients can query this information using files.collections.browse or files.collections.retrieve with the includeSupport flag.
retrieveProducts
Retrieve product support for all accessible providers
This endpoint will determine all providers that which the authenticated user has access to, in the current workspace. A user has access to a product, and thus a provider, if the product is either free or if the user has been granted credits to use the product.
This endpoint uses a specialized API for returning search results in a streaming fashion. In all other ways, this endpoint is identical to the normal search API.
This endpoint can be used instead of the normal search API as it will contact providers using the non-streaming version if they do not support it. In such a case, the core will retrieve multiple pages in order to stream in more content.
Clients should expect that this endpoint stops returning results after a given timeout. After which, it is no longer possible to request additional results.
The file can be of any type. If a directory is chosen then this will recursively copy all of its children. This request might fail half-way through. This can potentially lead to a situation where a partial file is left on the file-system. It is left to the user to clean up this file.
This operation handles conflicts depending on the supplied WriteConflictPolicy.
This is a long running task. As a result, this operation might respond with a status code which indicate that it will continue in the background. Progress of this job can be followed using the task API.
UCloud applied metadata will not be copied to the new file. File-system metadata (e.g. extended-attributes) may be moved, however this is provider dependant.
Errors:
Status Code
Description
400 Bad Request
The operation couldn't be completed because of the write conflict policy
404 Not Found
Either the oldPath or newPath exists or you lack permissions
This folder will automatically create parent directories if needed. This request may fail half-way through and leave the file-system in an inconsistent state. It is up to the user to clean this up.
Errors:
Status Code
Description
404 Not Found
Either the oldPath or newPath exists or you lack permissions
This call will recursively delete files if needed. It is possible that a provider might fail to completely delete the entire sub-tree. This can, for example, happen because of a crash or because the file-system is unable to delete a given file. This will lead the file-system in an inconsistent state. It is not guaranteed that the provider will be able to detect this error scenario. A client of the API can check if the file has been deleted by calling retrieve on the file.
emptyTrash
Permanently deletes all files from the selected trash folder thereby emptying it
This is a long running task. As a result, this operation might respond with a status code which indicate that it will continue in the background. Progress of this job can be followed using the task API.
Errors:
Status Code
Description
404 Not Found
Either the oldPath or newPath exists or you lack permissions
This request is sent by the client, if the client believes that initialization of resources might be needed. NOTE: This request might be sent even if initialization has already taken place. UCloud/Core does not check if initialization has already taken place, it simply validates the request.
The file can be of any type. This request is also used for 'renames' of a file. This is simply considered a move within a single directory. This operation handles conflicts depending on the supplied WriteConflictPolicy.
This is a long running task. As a result, this operation might respond with a status code which indicate that it will continue in the background. Progress of this job can be followed using the task API.
Errors:
Status Code
Description
400 Bad Request
The operation couldn't be completed because of the write conflict policy
404 Not Found
Either the oldPath or newPath exists or you lack permissions
This operation acts as a non-permanent delete for users. Users will be able to restore the file from trash later, if needed. It is up to the provider to determine if the trash should be automatically deleted and where this trash should be stored.
This is a long running task. As a result, this operation might respond with a status code which indicate that it will continue in the background. Progress of this job can be followed using the task API.
Errors:
Status Code
Description
404 Not Found
Either the oldPath or newPath exists or you lack permissions
A file in UCloud (UFile) closely follows the concept of a computer file you might already be familiar with. The functionality of a file is mostly determined by its type. The two most important types are the DIRECTORY and FILE types. A DIRECTORY is a container of UFiles. A directory can itself contain more directories, which leads to a natural tree-like structure. FILEs, also referred to as a regular files, are data records which each contain a series of bytes.
All files in UCloud have a name associated with them. This name uniquely identifies them within their directory. All files in UCloud belong to exactly one directory.
File operations must be able to reference the files on which they operate. In UCloud, these references are made through the id property, also known as a path. Paths use the tree-like structure of files to reference a file, it does so by declaring which directories to go through, starting at the top, to reach the file we are referencing. This information is serialized as a textual string, where each step of the path is separated by forward-slash / (U+002F). The path must start with a single forward-slash, which signifies the root of the file tree. UCloud never users 'relative' file paths, which some systems use.
All files in UCloud additionally have metadata associated with them. For this we differentiate between system-level metadata and user-defined metadata.
We have just covered two examples of system-level metadata, the id (path) and type. UCloud additionally supports metadata such as general stats about the files, such as file sizes. All files have a set of permissions associated with them, providers may optionally expose this information to UCloud and the users.
User-defined metadata describe the contents of a file. All metadata is described by a template (FileMetadataTemplate), this template defines a document structure for the metadata. User-defined metadata can be used for a variety of purposes, such as: Datacite metadata, sensitivity levels, and other field specific metadata formats.
Updates can optionally be fetched for a Resource. The updates describe how the Resource changes state over time. The current state of a Resource can typically be read from its status field. Thus, it is typically not needed to use the full update history if you only wish to know the current state of a Resource.
An update will typically contain information similar to the status field, for example:
A state value. For example, a compute Job might be RUNNING.
Change in key metrics.
Bindings to related Resources.
Properties
UploadProtocol
enumclassUploadProtocol { CHUNKED,}
Properties
WriteConflictPolicy
A policy for how UCloud should handle potential naming conflicts for certain operations (e.g. copy)