[fix] Infinite loop on some file operations

[T4g1]

Summary

• Closes [Testing] Validate hardlink/copy import behavior #598
• Help with [BUG] wild copy of root audiobook folder #438

Changes

Added

• Tests for hardlink operations
• Tests for recursive directory copy

Testing

Added automated testsings

Notes

This should not solve #438 but might help in some cases

[therobbiedavis]

Outside of the required rebase, I think this needs a few fixes before merging:

• Add a guard for destDir being inside sourceDir before the copy+delete fallback, so we don’t delete the destination and still return success.
• Split the robocopy fallback into separate file and directory paths; directory moves should use sourceDir, destDir, /MOVE, and the normal robocopy success range.
• Fix the recursive-copy test setup on Windows so it uses paths under the temp directory and actually reaches the behavior it’s trying to cover.
• Restore the temp-copy-then-rename behavior for the hardlink fallback, so an existing destination is not partially overwritten if the fallback copy fails.

[therobbiedavis]

I think this can leave source directories behind or report successful moves as failure because it only accepts exit code 1.

[T4g1]

I remember I had to change the exit code check because it was succeeding even when nothing was copied, I believe 1 is the only return code we can trust here for full completion. wdyt ?
Also, do you have evidence of this backup method being usefull ? I would expect robocopy to fail too if the initial move fails (why would robocopy succeed where move/library fails ?) I'd rather remove robocopy rather than adding more specific code path for it :x

[therobbiedavis]

So I dug in and verified this locally and validated that 1 is not quite enough with the current command. With /MOV "." /E, robocopy returned 1 and copied the files, but left the source directory tree behind. So it proves files were copied, not that the directory move completed.

Robocopy can be useful in some Windows-specific cases, but here it only runs after Directory.Move retries and the managed copy/delete fallback have both failed, so I don’t have strong evidence that it’s buying us much at that point, just trying to be proactive instead of responsive because admittedly it's tough to account for multiple OS architectures. I’m fine with removing the directory robocopy fallback instead of adding more logic if you feel confident. My main concern is just not returning true for a partial move. I'd imagine at some point down the line we may consider a helper or something to validate that everything was moved properly instead of relying on returns or exit codes.

[therobbiedavis]

Once we resolve either keeping and fixing the robocopy with a post-condition check, or remove it altogether, then this can be approved.