[Webkit-unassigned] [Bug 192562] New: [GLib] FileSystem::moveFile() should fall back to copying

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Dec 10 11:32:58 PST 2018


            Bug ID: 192562
           Summary: [GLib] FileSystem::moveFile() should fall back to
           Product: WebKit
           Version: Other
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: aperez at igalia.com

Note that:

 - Cocoa (in “Source/WebCore/platform/cocoa/FileSystemCocoa.mm”) uses
   [NSFileManager movItemAtURL:toURL:], which falls back to copying, as per

 - Windows (in “Source/WebCore/platform/win/FileSystemWin.cpp”) uses

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

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

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.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181210/1f079cb9/attachment.html>

More information about the webkit-unassigned mailing list