Skip to main content
Documentation

Understanding Usage with SFTP and Desktop App

The Files.com SFTP service and the Files.com Desktop App can record more download usage than the bytes your application actually consumes. This page explains why that happens and what you can do about it.

All other methods of accessing files with Files.com transfer only the exact bytes the client requests, so this page does not apply to them.

Why SFTP and Desktop Are Different

SFTP clients and desktop file systems are designed to make remote files behave like local files. Applications can read any part of a file, in any order, in any size. When a client starts reading a file from the beginning, it usually intends to read the whole thing, but the server has no way to know that in advance, and many SFTP clients issue reads in very small blocks, sometimes just a few kilobytes at a time.

Going back to storage for every tiny block would be too slow. To keep performance fast, the SFTP server and the Desktop App retrieve and cache more data than the application has asked for at any given moment, anticipating the next read. This is what makes SFTP and Desktop App downloads feel fast, and in normal use it works cleanly: the client reads the file straight through, the cache serves most reads, and bytes delivered match bytes pulled from storage.

Where the Mismatch Can Happen

A few situations leave bytes in the cache that the client never reads.

The most common case is an interrupted download. When a client (Files.com Desktop or a third-party SFTP client) disconnects mid-download because of a network drop, an app being closed, or a client-side timeout, any prefetched data that had not yet been sent to the client is discarded.

A small number of third-party SFTP clients, usually because of a poor implementation rather than intentional design, issue reads that jump around a large file instead of reading it straight through. Each jump can leave prefetched bytes that the client never reads.

Partial reads produce the same effect. When a client or application opens a file, reads a portion, and closes it without finishing, the cache filled in anticipation of further reads is discarded.

Why Files.com Works This Way

This behavior is a direct consequence of how SFTP and desktop file systems are designed. Neither protocol tells the server how much of a file the client intends to read, and both require fast responses to per-block requests. Caching and read-ahead are the only way to deliver good performance, and any caching strategy will sometimes prefetch bytes the client does not end up using.

For that reason, Files.com does not issue credits or refunds for usage that results from how a specific SFTP or Desktop client chooses to read files. The behavior is inherent to the protocols and is working as designed.

What To Do About It

The best way to avoid unexpected usage from these access patterns is to use one of the purpose-built Files.com Client Apps. These are optimized for the Files.com platform and handle files of all sizes efficiently: