Linux: implement pathCopy and fileRename, and fix three string functions

[greenfire27]

Five fixes to the Unix platform back-end, all of them things the other two back-ends have had working all along. Found by running the tests/ suites and the GoogleTest unit tests on Linux; none of this is specific to the branch that surfaced it.

Platform::pathCopy and Platform::fileRename were stubs

Both were return false; in platformX86UNIX/x86UNIXFileio.cc while Windows (winFileio.cc) and macOS (osxFileIO.mm) implement them. pathCopy returns a bool that almost nobody checks, so the work simply did not happen and everything downstream blamed the missing files.

What that broke on Linux:

• Creating a project produced an empty folder. The Project Manager stamps a new project out of a template with a recursive pathCopy (ProjectGamePanel.cs:100), and the new-project dialog copies the theme library the same way (NewProjectDialog.cs:146).
• Themes got no cursor art. Both AppCore and the Gui Editor give a theme its own copy of the stock cursors (themes.cs:130, GuiProfileEditorLibrary.cs:181).
• fileRename failed silently in ModuleManager (renaming a module definition) and ZipArchive (swapping a rebuilt archive into place). It has no script binding, so nothing script-side could see it either.

pathCopy now takes a file or a whole tree, since both callers exist. Paths are used as given rather than routed through MungePath into the pref directory, matching isFile/isDirectory/fileDelete beside it — every caller builds an absolute path and then asks isFile whether the copy arrived, so a copy landing elsewhere would read as a failure. Parent directories are created on that same raw path, because Platform::createPath would munge a relative one into the pref directory and leave the open to fail on a parent it had just made somewhere else.

Details worth keeping: the mode is carried across so a copied executable stays executable; a copy that fails partway is unlinked rather than left for the next run to mistake for real content; the recursion asks isDirectory rather than trusting dirent::d_type, which is DT_UNKNOWN on filesystems that do not carry the kind; and a tree is refused if the destination is inside it, which would otherwise recurse until the path outgrew MaxPath. Platform::isSubDirectory looks like it would answer that last question and does not — it matches a bare child name against the parent's entries, not one path inside another.

fileRename is rename(2) with a copy-and-delete fallback on EXDEV, since the pref directory and the game directory are not always on one filesystem.

Also removes dPathCopy: dead code that returned CopyFile's error flag as though it were a success flag, so anyone reaching for it would have got the answer backwards.

Three bugs in x86UNIXStrings.cc

Each was failing its own test in PlatformStringTests on every Linux run.

• dStrcatl walked one byte too far looking for the end of dst. while (dstSize && *p++) increments on the iteration that ends the loop too, so p came to rest past the terminator and the append landed in the wrong place: "Garage" + "Games" produced "Garage\0Games", which reads back as "Garage".
• dStrrev reversed nothing. The loop read x < 1 where it meant x < l, so it ran once and swapped only the first and last character — "GarageGames" came back as "sarageGameG". The corrected bound also keeps the XOR swap off the middle character of an odd-length string (which it would zero) and off str[-1] for an empty one.
• dItoa never terminated the string it had just built, so dStrrev's dStrlen read past the digits into whatever the caller's buffer held and reversed that: dItoa(16384) produced "\x7F83614". Terminating before the reverse is what the K&R original this is copied from does. While there, the digits are taken off an unsigned copy, because the old n = -n is undefined for S32_MIN — the one input that could not be printed at all.

These survive because Windows and macOS have their own copies of these functions and nobody runs the unit tests on Linux.

Testing

• New PlatformFileIOTests.PathCopyAndRename covers file copy, nooverwrite in both directions, a missing source leaving nothing behind, recursive tree copy, refusing a copy into itself, and rename. It is also the only way to reach fileRename, which has no script binding.
• runAllUnitTests() on Linux: 88 tests, 0 failures. Previously 3 failed.
• tests/run.sh: all 14 smoke suites green, no regressions.
• Verified against the Gui Editor branch (Gui Editor: an editor you can build a screen in #85) as well, where these fixes take cursorPane from 52 passed / 17 failed to 69 passed, 0 failed, and the full suite to 37/37.

Read the diff with whitespace shown if it looks odd — both files are CRLF in-tree and stay that way.

🤖 Generated with Claude Code