Whichever storage mechanism is enabled, the other persistent file should be deleted (either the plist or the db file).
rdar://problem/58696521
Created attachment 388450 [details] Patch
Comment on attachment 388450 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=388450&action=review > Source/WebKit/NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:167 > + auto persistentStorageFilePath = FileSystem::pathByAppendingComponent(resourceLoadStatisticsDirectory, "full_browsing_session_resourceLog.plist"); Let's name this variable "legacyPlistFilePath" to indicate that it is something we are migrating from and intent to remove support for in the future.
Created attachment 388750 [details] Patch
This was causing API test failures, I had to make some changes to the tests in this patch. Alex, I thought you might want to take another look before confirming r+.
Comment on attachment 388750 [details] Patch Clearing flags on attachment: 388750 Committed r255156: <https://trac.webkit.org/changeset/255156>
All reviewed patches have been landed. Closing bug.
<rdar://problem/58926444>
Comment on attachment 388750 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=388750&action=review > Source/WebKit/NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:168 > + if (FileSystem::fileExists(legacyPlistFilePath)) It's generally an anti-pattern to check for file-existence. Can we just attempt deletion and handle failure as needed? > Source/WebKit/NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:178 > + if (FileSystem::fileExists(databaseStorageFilePath)) { Ditto.