On a modern system, copying a folder into another is a twenty-line recursive function. On an Amiga 500 that same function is a time bomb: AmigaOS gives each process around 4 KB of stack, and every level of recursion wants a 260-byte FileInfoBlock plus two 256-byte paths. Five levels down you are standing on somebody else's memory. Which is why ChumOS, today, does not copy folders.
What it does do: one file, an 8 KB buffer
WBFSCopyFile opens source and destination, allocates an 8 KB buffer and shuttles between them until it is done. That is all. It does not walk subdirectories, does not build a tree, keeps no state between files. It is the boring operation you can reason about at a glance and test in an afternoon, and it is the only one the File Center actually offers.
Why the recursion does not fit
The problem is not writing it, it is the budget. One frame per level — FileInfoBlock, source path, destination path — is about 780 bytes. With 4 KB of stack that buys five levels before the stack eats whatever is underneath it, and with no MMU there is no warning: no exception, just silent corruption on a machine that cannot protect itself from itself. The known way out is to move the frames to the heap and drive the stack by hand, AllocMem per level with a depth counter. It is the right shape. It is not written.
The manual says "pending". That is exactly what it means: pending, not done.
The two traps waiting for whoever writes it
The first is copying a folder into itself: without a guard comparing destination path against source, the copy chases its own tail until the disk is full. The second is deleting while walking: in AmigaDOS, calling ExNext() on a directory you are modifying is undefined behaviour, and undefined on an A500 means it works sometimes and skips half a folder the rest of the time. The known fix is to re-read the first entry after every unlink, paying O(n²) in exchange for not losing files.
All of that is on the list, not on the floppy. We would rather ship a File Center that copies one file and copies it properly, and say so, than one that copies trees almost always.
D. ABELLÁN · FOUNDER · PRINCETON, IL · 2026.06.28