[webkit-reviews] review granted: [Bug 225289] Restore pre-r276879 behavior for FileSystem::deleteFile() and FileSystem::deleteEmptyDirectory() : [Attachment 427558] Patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon May 3 10:02:25 PDT 2021


Darin Adler <darin at apple.com> has granted Chris Dumez <cdumez at apple.com>'s
request for review:
Bug 225289: Restore pre-r276879 behavior for FileSystem::deleteFile() and
FileSystem::deleteEmptyDirectory()
https://bugs.webkit.org/show_bug.cgi?id=225289

Attachment 427558: Patch

https://bugs.webkit.org/attachment.cgi?id=427558&action=review




--- Comment #3 from Darin Adler <darin at apple.com> ---
Comment on attachment 427558
  --> https://bugs.webkit.org/attachment.cgi?id=427558
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=427558&action=review

> Source/WTF/wtf/FileSystem.cpp:493
>  bool deleteFile(const String& path)

Maybe later we want to add a new call that matches more directly what
std::filesystem::remove does, and remove these? I don’t think all callers
*need* to do the "only do it if it’s a file/directory" version; it’s just that
before we were starting by mirroring that feature of the POSIX API where unlink
is for files only and rmdir is for directories only. Now we are in a funny
place where we are more work for a semantic callers might not need.

> Source/WTF/wtf/FileSystem.cpp:506
>  bool deleteEmptyDirectory(const String& path)

Given the complexity of all the ".DS_Store" stuff on Mac, maybe we should
consider eventually getting rid of deleteEmptyDirectory to instead use a
function that can delete even non-empty ones. I suppose it’s a safety measure
to prevent deleting a lot of files that we use deleteEmptyDirectory.


More information about the webkit-reviews mailing list