From 0d593cf39a3c13b9061948a2bb9b6032e7430e85 Mon Sep 17 00:00:00 2001
From: SDL Wiki Bot <[EMAIL REDACTED]>
Date: Thu, 26 Sep 2024 23:29:38 +0000
Subject: [PATCH] Sync SDL3 wiki -> header
---
include/SDL3/SDL_filesystem.h | 29 ++++++++++++++---------------
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/include/SDL3/SDL_filesystem.h b/include/SDL3/SDL_filesystem.h
index 908cc1c71f1a4..673638540785a 100644
--- a/include/SDL3/SDL_filesystem.h
+++ b/include/SDL3/SDL_filesystem.h
@@ -308,8 +308,8 @@ extern SDL_DECLSPEC bool SDLCALL SDL_RemovePath(const char *path);
* Note that this will not copy files across filesystems/drives/volumes, as
* that is a much more complicated (and possibly time-consuming) operation.
*
- * Which is to say, if this function fails, SDL_CopyFile() to a temporary
- * file in the same directory as `newpath`, then SDL_RenamePath() from the
+ * Which is to say, if this function fails, SDL_CopyFile() to a temporary file
+ * in the same directory as `newpath`, then SDL_RenamePath() from the
* temporary file to `newpath` and SDL_RemovePath() on `oldpath` might work
* for files. Renaming a non-empty directory across filesystems is
* dramatically more complex, however.
@@ -330,26 +330,25 @@ extern SDL_DECLSPEC bool SDLCALL SDL_RenamePath(const char *oldpath, const char
* contents of the file at `oldpath`.
*
* This function will block until the copy is complete, which might be a
- * significant time for large files on slow disks. On some platforms, the
- * copy can be handed off to the OS itself, but on others SDL might just open
- * both paths, and read from one and write to the other.
+ * significant time for large files on slow disks. On some platforms, the copy
+ * can be handed off to the OS itself, but on others SDL might just open both
+ * paths, and read from one and write to the other.
*
* Note that this is not an atomic operation! If something tries to read from
- * `newpath` while the copy is in progress, it will see an incomplete copy
- * of the data, and if the calling thread terminates (or the power goes out)
+ * `newpath` while the copy is in progress, it will see an incomplete copy of
+ * the data, and if the calling thread terminates (or the power goes out)
* during the copy, `oldpath`'s previous contents will be gone, replaced with
* an incomplete copy of the data. To avoid this risk, it is recommended that
- * the app copy to a temporary file in the same directory as `newpath`, and
- * if the copy is successful, use SDL_RenamePath() to replace `newpath` with
- * the temporary file. This will ensure that reads of `newpath` will either
- * see a complete copy of the data, or it will see the pre-copy state of
- * `newpath`.
+ * the app copy to a temporary file in the same directory as `newpath`, and if
+ * the copy is successful, use SDL_RenamePath() to replace `newpath` with the
+ * temporary file. This will ensure that reads of `newpath` will either see a
+ * complete copy of the data, or it will see the pre-copy state of `newpath`.
*
* This function attempts to synchronize the newly-copied data to disk before
* returning, if the platform allows it, so that the renaming trick will not
- * have a problem in a system crash or power failure, where the file could
- * be renamed but the contents never made it from the system file cache to
- * the physical disk.
+ * have a problem in a system crash or power failure, where the file could be
+ * renamed but the contents never made it from the system file cache to the
+ * physical disk.
*
* If the copy fails for any reason, the state of `newpath` is undefined. It
* might be half a copy, it might be the untouched data of what was already