Bfile types
Batch file transfer
A job that moves a named set of files as one unit of work, with one success rule for the set.
How it works
The set can be a folder, a manifest, or a queue. Success is every member complete, or a documented partial with a retry list. Automation fits this term. A human dragging ten files also fits if the ticket treats them as one delivery. Per-file hashes roll up to a manifest hash.
A nightly batch sends 30 partner files. Twenty-nine land. The job status stays failed until the thirtieth retries and matches size. An alert that fired on the first success would have hidden the miss. The manifest lists 30 names. Twenty-nine is not the batch.
How it differs
Batch is not multipart. Multipart is one object in parts. Batch is many objects. People say batch for both and then abort the wrong thing.
A batch that stops on first error is safer than one that reports success with holes. Pick one policy and log it.
Order matters for some partners. A manifest with sequence numbers prevents a processor from reading file 2 before file 1 exists.
On the ticket
- The practical close is a log line: time, actor, byte count, result.
- Without that line the transfer is a story.
- With it, the next person can see whether this door did what the ticket claimed.
- If the path is shared, say so in the partner profile so a later change does not silently pick a different limit, key, or region.
- Count the finished object, not the first byte, before you close the ticket.
Related
Sources
- RFC 959, File Transfer Protocol
Control and data connections