Bug 225289 – Restore pre-r276879 behavior for FileSystem::deleteFile() and FileSystem::deleteEmptyDirectory()

• Component: Web Template Framework
• Status: RESOLVED FIXED

[Chris Dumez]

Restore pre-r276879 behavior for FileSystem::deleteFile() and FileSystem::deleteEmptyDirectory().

[Chris Dumez]

Created attachment 427537 [details]
Patch

[Chris Dumez]

Created attachment 427558 [details]
Patch

[Darin Adler]

Comment on attachment 427558 [details]
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.

[Chris Dumez]

(In reply to Darin Adler from comment #3)
> Comment on attachment 427558 [details]
> 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.

Yes, I agree. I will look into this. For now, I figure the safest choice is to maintain pre-existing behavior until I can check all call sites.

> 
> > 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.

I think we view deleteEmptyDirectory() as a way to avoid deleting non-webkit files in webkit folders. For example, I have a database IndexedDB.db in a IndexedDB/ folder and I want to remove the database. We usually call removeFile(IndexedDB.db) to remove our database, then deleteEmptyDirectory("IndexedDB/") to remove the folder but only if there is nothing else in it. I guess one worry is that the user might put a file in that WebKit directory and we wouldn't want to delete it. It seems unlikely to happen in practice but we try to stay on the safe side.

[EWS]

Committed r276906 (237251@main): <https://commits.webkit.org/237251@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 427558 [details].

[Radar WebKit Bug Importer]

<rdar://problem/77460938>