When using the Files.com S3-compatible endpoint, certain S3 operations behave differently from how they work on Amazon S3 or other object-storage systems. These differences ensure compatibility with the Files.com filesystem model and allow S3 access to work consistently with the rest of the platform.

No Recursive Listings

The Files.com S3-compatible endpoint does not perform recursive listings. Any ListObjects or ListObjectsV2 request returns only the items directly inside the targeted folder. Files inside subfolders, or in any deeper nested path, do not appear in the listing unless the client issues additional listing requests for those specific paths.

Many S3 clients automatically perform recursive listings by requesting a prefix with Delimiter=/. However, Files.com always returns a non-recursive listing, and clients must explicitly list each folder they want to explore.

Prefix Behavior

The S3 prefix parameter filters results within the targeted folder but does not cause Files.com to traverse subfolders. A prefix such as reports/2024/ returns only the contents of that folder. Subfolders require separate listing calls, even when a prefix matches a deeper path.

Client Compatibility Considerations

Some S3 clients assume that listing a prefix automatically returns all nested objects. When a client expects recursive behavior, it may appear to “miss” files or display incomplete results. To ensure full visibility, configure your client to list folders individually rather than relying on a single recursive listing.

Directory Semantics

Amazon S3 treats folders as logical prefixes, but Files.com maintains a true directory structure. Because the S3 protocol does not natively express this distinction, Files.com returns listings that reflect the actual directory layout. Clients that depend on object-storage behaviors, such as inferring empty directories from key names, should rely instead on standard folder listings for accuracy.