Prevent data-loss on rename if writing new file fails

[Osndok]

Description

As it currently stands, bruno relies upon itself holding data in memory during rename. If a write operation fails for any reason, we have a very good chance of losing user data. If we do the delete operation after the write, then we instead only risk duplication of data (if the unlink fails), which seems axiomatically correct.

Contribution Checklist:

• The pull request only addresses one issue or adds one feature.
• The pull request does not introduce any breaking changes
• I have added screenshots or gifs to help explain the change if applicable.
• I have read the contribution guidelines.
• Create an issue and link to the pull request.

Note: Keeping the PR small and focused helps make it easier to review and merge. If you have multiple changes you want to make, please consider submitting them as separate pull requests.

Publishing to New Package Managers

Please see here for more information.

[Osndok]

Related to #3454, #3274

[Pragadesh44-Bruno]

Hey @Osndok,

Thanks for raising a PR addressing this. I agree with your point that it is generally best to call unlink after a successful rewrite to minimize the risk of data loss.

However, the specific block you're referring to is written to handle a unique issue on Windows. Due to the file system's case insensitivity, filenames like Abc.bru and abc.bru are considered the same. In such cases, attempting a direct rename can fail or produce unexpected behavior. To address this, the implementation unlinks the file first, followed by writing the new file.

Additionally, there are scenarios where atomic renames cannot be performed, such as when dealing with case-insensitive file systems or cross-device operations. This implementation ensures compatibility with these edge cases.

[helloanoop]

@Osndok

There are some edge cases we need to handle as Pragadesh mentioned. We are discussing internally this and will get back to you.