Skip to main content

File Operations on Object Storage

For an explanation of how Files.com represents folders on object storage, see Representing Folders on Object Storage.

Object- and blob-based storage systems differ from traditional file systems in one fundamental way: they have no concept of rename or move. Every object is stored at a fixed key (its full path), and the only operations the storage layer supports are put (write), get (read), and delete.

This design means that file operations you perform through Files.com (deleting a file, renaming a folder, moving content) translate into sequences of lower-level put and delete calls that may look unexpected when observed from the storage provider's own console or audit log.

Deletions

How a deletion behaves depends on whether versioning is enabled on the bucket.

Without Versioning

When you delete a file on an object storage Remote Server without versioning enabled, Files.com issues a delete request for that object. The object is removed immediately and permanently. No recovery is possible through the storage provider unless you have a separate backup.

With Versioning

When you delete a file on a bucket with versioning enabled, the storage provider does not remove the object. Instead, it inserts a delete marker at that key. The file disappears from Files.com's standard file listing, but the object and all its previous versions remain in the bucket and continue to accrue storage costs.

From the storage provider's console, a deleted versioned object may appear differently depending on the provider:

  • On Amazon S3, the object is hidden from standard listings and only visible through the version history view.
  • On Backblaze B2, hidden objects remain visible in the bucket browser and are marked with an asterisk.

The data is not gone. It remains in storage, visible and recoverable from the provider's side, until you explicitly delete all versions.

Overwrites

How an overwrite behaves also depends on whether versioning is enabled on the bucket.

Without Versioning

When you write a new file to the same path as an existing file, the storage provider replaces the existing object with the new one. The previous content is permanently removed.

With Versioning

When versioning is enabled and you write a new file to the same path, the storage provider creates a new version of the object rather than replacing the old one. The previous version becomes a noncurrent version. It no longer appears in Files.com's standard file listing, but it remains in the bucket and continues to accrue storage costs.

Moving or Renaming a File

Object storage has no native move or rename operation. Files.com performs these operations as two steps:

  1. Copy the object to the new key (its new path or name).
  2. Delete the object from the original key.

If versioning is enabled, the delete in step two creates a delete marker at the original key rather than removing the object.

Moving or Renaming a Folder

Renaming or moving a folder in object storage is more involved than renaming a single file. There are no real folders in object storage, only object keys that share a common prefix, so renaming a folder requires rewriting every key under that prefix.

Files.com performs a folder rename or move as follows:

  1. List all objects under the source folder prefix.
  2. Copy each object to a new key under the destination prefix.
  3. Delete each original object at the source prefix.

For a folder containing hundreds or thousands of files, this produces hundreds or thousands of individual copy and delete operations.

If versioning is enabled on the bucket, step three produces a delete marker for each object at its original key. From the storage provider's console, this appears as a large number of deletions or hidden-file events happening in rapid succession, even though the data has not been lost. The files are simultaneously present at their new locations and marked as hidden (or marked with an asterisk, on Backblaze B2) at their old ones.

This is expected behavior. The renamed folder is intact and fully accessible through Files.com. The delete markers and version history at the old paths are a side effect of how object storage handles rename operations. They can be cleaned up by permanently deleting the noncurrent versions and delete markers at the old paths through the storage provider's console.