File Operations on Object Storage
On flat-namespace object storage, a file's path is an object key and a folder is a shared key prefix. Renaming or moving content can require copying objects and deleting their original keys. See Representing Folders on Object Storage for how Files.com presents these paths as folders.
The resulting operations may appear as separate writes and deletions in the provider's console or audit log. Provider features such as versioning, soft delete, and lifecycle policies determine what remains recoverable and what continues to incur storage charges.
Deletions
Files.com sends a delete request for the current object. Recovery depends on the remote provider's retention settings; Files.com's standard file listing does not expose retained versions or soft-deleted objects.
Without Versioning
Without versioning or another recovery feature, deletion removes the object permanently. Some providers offer soft delete independently of versioning. Check the provider's configuration and recovery window before relying on either behavior.
With Versioning
Versioned Amazon S3 buckets retain previous versions and add a delete marker when the current object is deleted. Backblaze B2 similarly retains file versions and uses hide markers. Other providers implement version retention differently; do not assume every service uses S3 delete markers.
Retained versions can continue to incur storage charges even though the file no longer appears in Files.com. Manage recovery and expiration through the storage provider's version history and lifecycle settings.
Overwrites
Writing to an existing path creates a new current object. Retention settings determine whether the previous content remains available through the provider.
Without Versioning
An overwrite replaces the current content. Recovery requires another provider feature, such as soft delete, or a separate backup.
With Versioning
The previous content remains as a noncurrent version until the provider's retention or lifecycle rules remove it. Files.com's standard file listing shows the current version only.
Moving or Renaming a File
For object-storage connections that use copy-and-delete moves, Files.com performs two operations:
- Copy the object to its new key.
- Delete the object at its original key.
These operations are not atomic. A failure can leave a copy at the destination while the source remains. With versioning or soft delete, the provider may also retain the original content after a successful move.
Moving or Renaming a Folder
For a flat namespace, Files.com lists the objects under the source prefix, copies them to the destination prefix, and deletes the originals. A folder with thousands of files requires thousands of object operations. Check the operation's result before assuming all files have moved.
After a successful move, current files appear at their new paths. Version history, delete markers, or soft-deleted content can remain at the old paths according to the provider's retention settings. Use provider lifecycle rules or administrative tools to manage those retained objects.
Providers with hierarchical namespaces can support directory operations that differ from this model. See Azure Blob Storage Hierarchical Namespace for the behavior of that Files.com connection.