*Nuke ?

The RISC OS sources archive comes to 14,285 files (376,418,347MiB).
If I download and unpack the current sources, the older ones will need to be deleted.

The problem is that deletion is incredibly slow and I suspect it may clobber the SD card somewhat with deleting every single file one by one.

Has anybody written a utility that will walk a directory structure and erase it from the bottom up an entire directory at a time? Not by erasing files, but low level so can so it in one pass per directory.

walk a directory structure and erase it

True erase for security or DOS/Windows style blank the FAT pointer? Writing the latter version is probably easier and the results are likely to be quicker.

Could the OS if it spotted that the complete contents of a directory was being deleted, write out the changes in one go?
Having subdirectories would add the the problem I suspect.

Does each file & directory deleted need to be added to the free space map? Which may mean that the directory structure has to be walked to find their location & length.

It’s up to the filing system itself how many writes it performs to the SD card, since – and this is a pet peeve of mine – FileSwitch will simply recursively descend the directory tree, issuing ‘delete single file’ or ‘delete empty directory’ calls to the FS. IMHO, filing system operations on all platforms suffer a lot from not being designed such that each API call accepts a list of ‘n’ files with ‘n==1’ being the dimunitive case. Acting on ‘n’ objects by iterating n times an API call of ‘do this to 1 object’ is inherently inefficient, and at best, forces the lower layers to intelligently recombine the operations in some way to reduce traffic to/from the storage medium.

I rather suspect that whatever FS you’re using on RISC OS will be performing write-through for every single operation, which minimises the risk of disk corruption, but at the expense of performance. If it’s a FAT medium, you could perform the delete on Linux or Windows, which defer write operations at the lower level of the FS hierarchy resulting in less disk traffic, but – of course – still a lot of unnecessary processing.

Perhaps it would be worth storing the build tree on a medium of its own so that you could just reformat it?