Note that: - Cocoa (in “Source/WebCore/platform/cocoa/FileSystemCocoa.mm”) uses [NSFileManager movItemAtURL:toURL:], which falls back to copying, as per https://developer.apple.com/documentation/foundation/nsfilemanager/1414750-moveitematurl?language=objc - Windows (in “Source/WebCore/platform/win/FileSystemWin.cpp”) uses MoveFileEx(), passing flags MOVEFILE_COPY_ALLOWED|MOVEFILE_REPLACE_EXISTING But in the other hand: - “Source/WebCore/platform/posix/FileSystemPOSIX.cpp” uses a plain rename(2), which does NOT fall-back to copying. - “Source/WebCore/platform/glib/FileSystemGlib.cpp” uses g_rename(), which ends up calling rename(2) -- why this does not simply use the POSIX implmentation beats me ¯\_(ツ)_/¯ While working on the content extensions code, I have noticed that compiling a content extension involves creating a temporary file, and then moving it to its final location. For the GLib-based ports (GTK+, WPE) on Unix, the temporary file will be created under “/tmp”, and then FileSystem::moveFile() is used to place it in its final location, typically under the user's $HOME directory. There is a catch, though: frequently “/tmp” is on a different mount point than the final location! This is *very* often true in modern GNU/Linux distributions that have “/tmp” on tmpfs. Or, even if “/tmp” is the same file system as “/”, not uncommonly “/home” can be a separate file system itself. To me it is quite clear that FileSyste::moveFile() has to fall-back to copying, otherwise anything that makes use if this function will be far too easy to randomly break in unexptected ways.
For FileSystemGLib I am planning to rewrite the function to use g_file_move(), which does implements a copy+delete fallback.
Created attachment 356977 [details] Patch
Comment on attachment 356977 [details] Patch Clearing flags on attachment: 356977 Committed r239043: <https://trac.webkit.org/changeset/239043>
All reviewed patches have been landed. Closing bug.
<rdar://problem/46604998>