Skip to main content
Documentation

Understanding Usage with SFTP and Desktop App

This article is focused on the use of Files.com SFTP service and the Files.com Desktop App. This article explains the download usage and bandwidth in edge cases where transfer usage can exceed what your application actually used, and what you can do about it.

For all other methods of accessing files with Files.com, this article does not apply. Those protocols let the client request exactly the bytes it wants, and Files.com transfers only those bytes.

Why SFTP and Desktop Are Different

SFTP clients and desktop file systems are designed to make remote files behave like local files. That means applications can read any part of a file, in any order, in any size. Most of the time, when a client starts reading a file (especially from the beginning), it 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 unbearably slow. To keep performance fast, our SFTP server and Desktop App retrieve and cache more data than the application has asked for at any given moment, anticipating the next read. This method is what makes SFTP and Desktop App downloads feel fast, and in the vast majority of real-world use it works beautifully: 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

There are a few situations where the cache holds bytes the client never reads.

Interrupted downloads - This is the most common case. If a client (Files.com Desktop or 3rd party SFTP Clients) disconnects mid-download (network drop, user closes the app, client-side timeout), any prefetched data that had not yet been sent to the client is discarded.

Poorly behaved clients doing random reads - A small number of 3rd party SFTP clients, usually due to a bad implementation rather than intentional design, issue reads that jump around a large file instead of reading it straight through.

Partial reads - If a client or an application opens a file, reads a portion, and then closes it without finishing, the cache filled in anticipation of further reads is discarded, the same way an interrupted download behaves.

Why Files.com Works This Way

This behavior is a fundamental 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 occasionally 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 it 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 our purpose-built Files.com Client Apps. These are optimized for the Files.com platform, deliver the fastest transfer speeds available, and handle files of all sizes efficiently without triggering the edge cases described above: