Round trips per file
Over a 150 ms path, a transfer that negotiates each file spends most of its time waiting rather than sending.
Large directory transfer
Move folders with hundreds of thousands of files as one job.
A folder of 400,000 small files defeats tools that treat every file as its own transfer. RIPTON CLOUD packages the directory once, moves it as one stream, and keeps the tree exactly as it was.
The 100,000-file figure is RIPTON CLOUD's published EC2 benchmark at roughly 150 ms latency and 3% packet loss with 512-byte files. Results depend on your files, route, endpoints, and storage.
Evaluated transfer path
01
Directory tree
02
RIPTON packaging
03
RIPTON node
04
Same tree, other side
The many-small-files problem
Per-file overhead, not bandwidth, is what makes directory transfers crawl.
Every file costs a round trip to open, a round trip to acknowledge, and a directory entry to create. Multiply by a few hundred thousand and a gigabit link delivers kilobytes per second while the disk and the protocol do bookkeeping.
Disk operations per file
Creating and closing hundreds of thousands of small files is bound by the destination's IOPS, not by the network.
Fragile at scale
One failure in file 312,000 restarts a job, or leaves a half-copied tree nobody can trust.
Workflows
Where the transfer path matters most.
EXR · DPX · TIFF sequences
Image and frame sequences
Send a shot as the sequence it is, thousands of frames in named order, and receive it as the same sequence.
Training sets · results · project trees
Dataset and code trees
Move research datasets, model checkpoints, and repository snapshots with their directory structure preserved.
Document stores · mail archives · system exports
Exports and migrations
Deliver an application or archive export with its many small files as one verified package inside the operating window.
RIPTON CLOUD in the workflow
How RIPTON CLOUD handles the file count
The product earns its place by moving prepared data between endpoints—not by claiming ownership of every system around it.
One package, not a million transfers
Files are packed into a single bundle as they leave, sent as one stream, and stored as one object at the destination, so the network and the disk see sequential data.
Structure preserved
Relative paths, nesting, and names arrive exactly as they left. Recipients download the tree or any file in it.
Browser and Desktop paths
In the browser, files are read in parallel and sent in batches of a thousand. RIPTON Desktop packages locally and uses the accelerated protocol end to end.
Measured, not asserted
In RIPTON CLOUD's published EC2 test, a directory of 100,000 files finished in 0.98 seconds against 2 minutes 52 seconds for the TCP baseline, on a path with 150 ms latency and 3% loss.
No generic speed promise
Your tree, your route, and your destination storage set the result. The evaluation below is how the number gets written down for your case rather than assumed.
Product boundary
A transfer layer for directories, with clear edges.
RIPTON CLOUD moves a directory as it exists at send time. It does not watch it for changes afterwards, and it does not replace the systems that manage the files.
What it covers
- Directories of any file count within the plan's transfer allowance
- Preserved paths, names, and nesting
- Progress by bytes and by files while the job runs
- Encrypted transfer between evaluated endpoints
What stays with your stack
- Two-way synchronization or change watching
- Deduplication across separate packages
- Permission and ACL replication between operating systems
- Asset or dataset catalog management
Evaluation path
Test it with your own tree
Directory workloads are where tool differences are largest, and where the result is easiest to measure: file count, total size, route, elapsed time.
- 01
Pick a representative directory
The real sequence, dataset, or export, or a copy with the same file count and size distribution.
- 02
Record the baseline
Time the current tool on the same route and note failures, restarts, and how long the destination took to become usable.
- 03
Send it with RIPTON CLOUD
From the browser for a quick check, or with RIPTON Desktop for the accelerated path. Progress shows files and bytes as they move.
- 04
Compare on the numbers
Elapsed time, delivered file count, and whether the tree matched. If the gap is not meaningful on your route, you know quickly.
FAQ
Questions technical buyers ask.
Do I have to zip the folder first?
No. Select the folder and send it. RIPTON CLOUD packages the files itself as they are read, so there is no separate archive step and nothing to unpack on the other side.
Is there a limit on the number of files?
There is no fixed file-count limit. The plan's monthly transfer allowance and per-file size limit apply; a directory of several hundred thousand small files is a normal workload.
What happens if the transfer is interrupted?
Browser transfers resume from the last completed batch, and RIPTON Desktop transfers resume from the last verified block. A completed package is verified before it is marked delivered.
Can recipients download a single file from a large directory package?
Yes. Recipients can download the whole package as an archive or pick individual files from the tree in their browser.
Why is my current tool so slow on small files even on a fast link?
Because it pays a round trip and a disk operation for every file. On a long path that overhead dominates; the link is idle most of the time. Packaging the directory once removes that cost, which is what the 100,000-file benchmark shows.
Technical evaluation
Bring the folder that takes all night.
We will help you time it on your route against what you use today, with the file count and conditions written down.