Bug 315236
| Summary: | Content rule list store may end up copying compiled bytecode files | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Adrian Perez <aperez> |
| Component: | WebKit Misc. | Assignee: | Adrian Perez <aperez> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | nekohayo, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=315135 | ||
| Bug Depends on: | |||
| Bug Blocks: | 252846, 267774, 291796 | ||
Adrian Perez
When compiling a JSON rule list, the flow is roughly:
1. Calculate the destination location for the compiled file.
2. Create a temporary file, using WTF::openTemporaryFile().
3. Write compiled bytecode to the temporary file.
4. Delete the destination file (if exists).
5. Use WTF::moveFile() to “rename” the temporary file in the final location.
The issue here is that (2.) uses a platform-dependent temporary directory for
created temporary files, and for some ports it can easily end up being in a file
system different than the final destination, resulting in WTF::moveFile() falling
back to a *synchronous* copy.
Case example: the GTK and WPE ports use g_get_tmp_dir() for the temporary
file location, which most of the time will be /tmp. On modern Linux distributions
and embedded devices this can very easily be in-memory (tmpfs), and/or the
user's home directory (where programs will configure the ContentRuleListStore
data directory) may be on its own volume.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Adrian Perez
Pull request: https://github.com/WebKit/WebKit/pull/65336
EWS
Committed 313681@main (0a4e6af65950): <https://commits.webkit.org/313681@main>
Reviewed commits have been landed. Closing PR #65336 and removing active labels.
Radar WebKit Bug Importer
<rdar://problem/177635088>