WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
197684
[Win] Implement NetworkCache::Data by using FileSystem::MappedFileData
https://bugs.webkit.org/show_bug.cgi?id=197684
Summary
[Win] Implement NetworkCache::Data by using FileSystem::MappedFileData
Fujii Hironori
Reported
2019-05-07 21:07:48 PDT
[Win] Implement NetworkCache::Data by using FileSystem::MappedFileData We need to implement FileSystem::MappedFileData for Windows first.
Attachments
patch
(27.39 KB, patch)
2020-01-30 15:35 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
patch
(29.39 KB, patch)
2020-01-30 16:24 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
patch
(30.37 KB, patch)
2020-01-31 13:56 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
patch
(30.46 KB, patch)
2020-01-31 13:59 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
patch
(31.94 KB, patch)
2020-01-31 16:11 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
patch
(31.96 KB, patch)
2020-01-31 16:20 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
patch
(30.58 KB, patch)
2020-02-04 15:10 PST
,
Christopher Reid
achristensen
: review-
Details
Formatted Diff
Diff
patch
(32.41 KB, patch)
2020-02-11 13:59 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
patch
(33.27 KB, patch)
2020-02-13 15:32 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
patch
(33.28 KB, patch)
2020-02-13 15:38 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
patch
(34.31 KB, patch)
2020-02-18 18:48 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
patch
(34.32 KB, patch)
2020-02-18 18:51 PST
,
Christopher Reid
koivisto
: review-
Details
Formatted Diff
Diff
Patch
(39.83 KB, patch)
2020-02-20 17:35 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
patch
(38.83 KB, patch)
2020-02-20 17:39 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
Patch
(36.29 KB, patch)
2020-02-25 00:49 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
patch
(36.33 KB, patch)
2020-02-25 14:18 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
Patch for landing
(37.46 KB, patch)
2020-02-26 10:52 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
Patch for landing
(37.41 KB, patch)
2020-02-26 10:57 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
Patch for landing
(37.41 KB, patch)
2020-02-26 13:05 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
Patch for landing
(37.44 KB, patch)
2020-02-26 13:57 PST
,
Christopher Reid
no flags
Details
Formatted Diff
Diff
Show Obsolete
(19)
View All
Add attachment
proposed patch, testcase, etc.
Fujii Hironori
Comment 1
2019-05-07 21:10:25 PDT
See also
Bug 196289 Comment 28
.
Fujii Hironori
Comment 2
2019-05-26 22:11:18 PDT
(In reply to Fujii Hironori from
comment #0
)
> We need to implement FileSystem::MappedFileData for Windows first.
Filed this in
Bug 198269
.
Christopher Reid
Comment 3
2020-01-30 15:35:34 PST
Created
attachment 389293
[details]
patch WinCairo now passes 30/31 disk-cache tests with these changes.
Christopher Reid
Comment 4
2020-01-30 16:24:03 PST
Created
attachment 389299
[details]
patch Fixing style and GTK/Mac build issues
Christopher Reid
Comment 5
2020-01-31 13:56:08 PST
Created
attachment 389410
[details]
patch more build fixes and fixing GTK assert
Christopher Reid
Comment 6
2020-01-31 13:59:41 PST
Created
attachment 389411
[details]
patch style fixes
Christopher Reid
Comment 7
2020-01-31 16:11:06 PST
Created
attachment 389437
[details]
patch Adding flag to FileSystem::openFile can open with 0600 directly instead of 0666 then fchmod to 0600.
Christopher Reid
Comment 8
2020-01-31 16:20:43 PST
Created
attachment 389438
[details]
patch fixing mac builds
Fujii Hironori
Comment 9
2020-02-02 20:13:30 PST
Comment on
attachment 389438
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=389438&action=review
> LayoutTests/platform/wincairo/TestExpectations:856 > +
Sort alphabetically. Put http/tests/cache/* after http/tests/blink/sendbeacon before http/tests/cache-storage .
> Source/WTF/wtf/win/FileSystemWin.cpp:439 > + creationDisposition = CREATE_ALWAYS;
CREATE_ALWAYS always truncates the file. Why is this OK?
> Source/WTF/wtf/win/PathWalker.cpp:35 > + String path = makeString(directory, "\\"_s, pattern);
'\\' is slightly better than "\\"_s.
> Source/WebKit/NetworkProcess/cache/NetworkCacheDataCurl.cpp:47 > + return Data(WTF::nullopt);
This is null Data. Data::empty() returns the empty Data in other ports. Is this OK?
Christopher Reid
Comment 10
2020-02-03 18:50:41 PST
(In reply to Fujii Hironori from
comment #9
)
> Comment on
attachment 389438
[details]
> patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=389438&action=review
> > > LayoutTests/platform/wincairo/TestExpectations:856 > > + > > Sort alphabetically. Put http/tests/cache/* after > http/tests/blink/sendbeacon before http/tests/cache-storage . >
will fix this.
> > Source/WTF/wtf/win/FileSystemWin.cpp:439 > > + creationDisposition = CREATE_ALWAYS; > > CREATE_ALWAYS always truncates the file. Why is this OK? >
It seems like this was only working for this case because if the file exists it gets deleted before this call so it's not called with a non-empty file.
https://github.com/WebKit/webkit/blob/master/Source/WebKit/NetworkProcess/cache/NetworkCacheBlobStorage.cpp#L111
. O_RDWR doesn't seem needed for this case then.
> > Source/WTF/wtf/win/PathWalker.cpp:35 > > + String path = makeString(directory, "\\"_s, pattern); > > '\\' is slightly better than "\\"_s. >
will fix this.
> > Source/WebKit/NetworkProcess/cache/NetworkCacheDataCurl.cpp:47 > > + return Data(WTF::nullopt); > > This is null Data. Data::empty() returns the empty Data in other ports. Is > this OK?
Right, this should use an empty vector instead of null.
Christopher Reid
Comment 11
2020-02-04 15:10:23 PST
Created
attachment 389719
[details]
patch updated patch
Brent Fulgham
Comment 12
2020-02-05 11:26:49 PST
Comment on
attachment 389719
[details]
patch I think this patch looks good from the Windows code standpoint, but we need Antti or another cache person to double-check the cache logic.
Alex Christensen
Comment 13
2020-02-05 15:32:45 PST
Comment on
attachment 389719
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=389719&action=review
> Source/WTF/wtf/FileSystem.cpp:336 > + default: > + ASSERT_NOT_REACHED();
Could we remove the default and put EventsOnly?
> Source/WTF/wtf/FileSystem.h:87 > +enum class FileAccessPermission {
: bool
> Source/WTF/wtf/posix/FileSystemPOSIX.cpp:96 > platformFlag |= O_EVTONLY;
Please also change this to a switch.
> Source/WTF/wtf/win/FileSystemWin.cpp:638 > + default: > + ASSERT_NOT_REACHED();
Again, please remove the default.
> Source/WebKit/NetworkProcess/cache/NetworkCacheDataCurl.cpp:96 > + memcpy(buffer.data(), map, size);
Do we really want this memcpy here? Doesn't that defeat the purpose of having mapped memory?
Adrian Perez
Comment 14
2020-02-05 16:25:32 PST
Comment on
attachment 389719
[details]
patch Overall it's super nice to see common code being cleaned up and operating system specific guards being removed \o/ Adding to Alex's comments, the changes to the GLib/Soup/Unix bits look good to me, with the caveat that the API test /webkit/WebKitWebsiteData/databases is not supposed to be flaky so I would say we need it to keep it passing before we can land this—please drop me a line (or anyone else) on IRC if you need a hand figuring out why it might be failing :-] View in context:
https://bugs.webkit.org/attachment.cgi?id=389719&action=review
> Source/WTF/wtf/posix/FileSystemPOSIX.cpp:103 > + permissionFlag |= 0666;
I would probably use (S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH) for the sake of consistency, even though 0666 is a common idiom. (Note: with _BSD_SOURCE there is a DEFFILEMODE macro which expands to the expression above, but it won't be available in all systems so I'd rather avoid using this macro.)
Christopher Reid
Comment 15
2020-02-11 13:59:25 PST
Created
attachment 390418
[details]
patch Updated patch addressing comments from Alex and Adrian. I updated NetworkCacheDataCurl to use a ref counted Variant<Vector<uint8_t>, FileSystem::MappedFileData> to act like the ref counted buffers for mmap/allocated containers in Soup and Mac ports so the mapped file can be kept around. I'll be digging in to that GTK failure today.
Fujii Hironori
Comment 16
2020-02-12 01:49:51 PST
Comment on
attachment 390418
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=390418&action=review
> Source/WTF/wtf/win/FileSystemWin.cpp:-438 > - ASSERT_NOT_REACHED();
Why did you remove this ASSERT_NOT_REACHED? IIRC, MSVC reports compilation warnings.
> Source/WTF/wtf/win/FileSystemWin.cpp:551 > + if (!GetDiskFreeSpaceExW(path.wideCharacters().data(), &freeBytesAvailableToCaller, &totalNumberOfBytes, &totalNumberOfFreeBytes))
GetDiskFreeSpaceExW can take NULL. Replace totalNumberOfBytes, totalNumberOfFreeBytes with nullptr.
> Source/WTF/wtf/win/FileSystemWin.cpp:554 > + if (freeBytesAvailableToCaller.QuadPart > static_cast<ULONGLONG>(std::numeric_limits<uint64_t>::max()))
ULONGLONG and uint64_t are same in x64 Windows. Is this code only for 32bit Windows? If so, how about enclosing it with #if defined(_M_IX86).
https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types
> Source/WTF/wtf/win/FileSystemWin.cpp:555 > + return false;
If you have plenty of storage, it always return false. What do you think returning std::numeric_limits<uint64_t>::max() in this case?
> Source/WebKit/NetworkProcess/cache/NetworkCacheData.h:102 > + Box<Variant<Vector<uint8_t>, FileSystem::MappedFileData>> m_buffer;
Box<T> manages T as ThreadSafeRefCounted. Do you need to manage T by thread-safe and ref-counted? What about using Optional<T> or unique_ptr<T> ? Variant is already marked by WTF_MAKE_FAST_ALLOCATED.
Konstantin Tokarev
Comment 17
2020-02-12 04:09:55 PST
(In reply to Fujii Hironori from
comment #16
)
> Comment on
attachment 390418
[details]
> patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=390418&action=review
> > > Source/WTF/wtf/win/FileSystemWin.cpp:-438 > > - ASSERT_NOT_REACHED(); > > Why did you remove this ASSERT_NOT_REACHED? IIRC, MSVC reports compilation > warnings.
If assert is really needed to avoid warning, then release build should have this warning because it's not a RELEASE_ASSERT_NOT_REACHED()
Christopher Reid
Comment 18
2020-02-12 14:03:39 PST
Comment on
attachment 390418
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=390418&action=review
>>> Source/WTF/wtf/win/FileSystemWin.cpp:-438 >>> - ASSERT_NOT_REACHED(); >> >> Why did you remove this ASSERT_NOT_REACHED? IIRC, MSVC reports compilation warnings. > > If assert is really needed to avoid warning, then release build should have this warning because it's not a RELEASE_ASSERT_NOT_REACHED()
Right should be a warning in MSVC if there was an unhandled enum class value. All the FileOpenMode cases for windows are handled here so we shouldn't get a warning.
>> Source/WTF/wtf/win/FileSystemWin.cpp:551 >> + if (!GetDiskFreeSpaceExW(path.wideCharacters().data(), &freeBytesAvailableToCaller, &totalNumberOfBytes, &totalNumberOfFreeBytes)) > > GetDiskFreeSpaceExW can take NULL. Replace totalNumberOfBytes, totalNumberOfFreeBytes with nullptr.
That's good to know, I'll take them out.
>> Source/WTF/wtf/win/FileSystemWin.cpp:554 >> + if (freeBytesAvailableToCaller.QuadPart > static_cast<ULONGLONG>(std::numeric_limits<uint64_t>::max())) > > ULONGLONG and uint64_t are same in x64 Windows. Is this code only for 32bit Windows? > If so, how about enclosing it with #if defined(_M_IX86). >
https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types
Oh yeah this seems pretty redundant even on 32-bit windows. On 32-bit ULONGLONG and uint64_t should still both have at least 64-bits of storage. I'll remove this check.
>> Source/WebKit/NetworkProcess/cache/NetworkCacheData.h:102 >> + Box<Variant<Vector<uint8_t>, FileSystem::MappedFileData>> m_buffer; > > Box<T> manages T as ThreadSafeRefCounted. Do you need to manage T by thread-safe and ref-counted? > What about using Optional<T> or unique_ptr<T> ? > Variant is already marked by WTF_MAKE_FAST_ALLOCATED.
I used this ref-counted container here because there's currently some cases where this class is copied and needs to manage multiple instances of the data. The case I remember seeing was
https://github.com/WebKit/webkit/blob/master/Source/WebKit/NetworkProcess/cache/NetworkCacheStorage.cpp#L99
Christopher Reid
Comment 19
2020-02-13 15:32:10 PST
Created
attachment 390697
[details]
patch Updated patch
Christopher Reid
Comment 20
2020-02-13 15:38:39 PST
Created
attachment 390698
[details]
patch Style fix
Christopher Reid
Comment 21
2020-02-13 15:48:23 PST
This should also fix the GTK failure. It seemed to be a pre-existing problem where the CacheStorage directory wasn't being created for ports without SandboxExtensions. Before trying to open CacheStorage/salt was failing silently. Now with these FileSystem changes GTK's writeToFile fails an assert if the handle isn't valid. That directory should now be created properly for all ports.
Fujii Hironori
Comment 22
2020-02-13 18:09:51 PST
Comment on
attachment 390698
[details]
patch LGTM
Adrian Perez
Comment 23
2020-02-14 02:04:25 PST
(In reply to Christopher Reid from
comment #21
)
> This should also fix the GTK failure. > > It seemed to be a pre-existing problem where the CacheStorage directory > wasn't being created for ports without SandboxExtensions. > > Before trying to open CacheStorage/salt was failing silently. > Now with these FileSystem changes GTK's writeToFile fails an assert if the > handle isn't valid. > > That directory should now be created properly for all ports.
Nicer find! 💪
WebKit Commit Bot
Comment 24
2020-02-14 12:05:51 PST
The commit-queue encountered the following flaky tests while processing
attachment 390698
[details]
: editing/spelling/spellcheck-async-remove-frame.html
bug 158401
(authors:
morrita@google.com
,
rniwa@webkit.org
, and
tony@chromium.org
) The commit-queue is continuing to process your patch.
WebKit Commit Bot
Comment 25
2020-02-14 12:06:33 PST
Comment on
attachment 390698
[details]
patch Clearing flags on attachment: 390698 Committed
r256633
: <
https://trac.webkit.org/changeset/256633
>
WebKit Commit Bot
Comment 26
2020-02-14 12:06:35 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 27
2020-02-14 12:07:14 PST
<
rdar://problem/59467397
>
WebKit Commit Bot
Comment 28
2020-02-14 22:46:47 PST
Re-opened since this is blocked by
bug 207807
Christopher Reid
Comment 29
2020-02-18 18:48:15 PST
Created
attachment 391124
[details]
patch I ended up re-adding FileOpenMode::ReadWrite since mmap was failing on FileSystemPOSIX when the file was created with O_WRONLY. That caused the memory regression in Mac. I also wanted to check if O_EXCL is needed on this NetworkCacheData mapped file before re-landing. I didn't carry it over to FileSystem::openFile implementations since I don't think most openFile calls using ReadWrite will want to always create a file. Also the parent directory for the caches are created with S_IRWXU access. If O_EXCL is needed it might make sense then to have something like a FileSystem::createFile call that fails if the file already exists.
Christopher Reid
Comment 30
2020-02-18 18:51:57 PST
Created
attachment 391126
[details]
patch fixing gtk build
Yusuke Suzuki
Comment 31
2020-02-19 11:02:46 PST
Note that I already run the patch offered by Chris and ensured that new patch does not cause Membuster regression on macOS.
Antti Koivisto
Comment 32
2020-02-20 09:09:42 PST
Comment on
attachment 391126
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=391126&action=review
> Source/WebKit/NetworkProcess/cache/NetworkCacheData.cpp:45 > - int fd = open(FileSystem::fileSystemRepresentation(path).data(), O_CREAT | O_EXCL | O_RDWR , S_IRUSR | S_IWUSR); > - if (fd < 0) > - return { }; > - > - if (ftruncate(fd, m_size) < 0) { > - close(fd); > + auto handle = FileSystem::openFile(path, FileSystem::FileOpenMode::ReadWrite, FileSystem::FileAccessPermission::User); > + if (!FileSystem::truncateFile(handle, m_size)) { > + FileSystem::closeFile(handle);
Please don't lose O_EXCL (or any other flags). Otherwise in error situation we'l truncate a file backing an existing mapping. This will crash hard.
Christopher Reid
Comment 33
2020-02-20 17:35:43 PST
Created
attachment 391361
[details]
Patch Added FileSystem::createFile to keep the O_EXCL flag. It will return an invalid handle if the file already exists.
Christopher Reid
Comment 34
2020-02-20 17:39:27 PST
Created
attachment 391362
[details]
patch mac build fix
Antti Koivisto
Comment 35
2020-02-20 23:47:47 PST
Comment on
attachment 391362
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=391362&action=review
> Source/WTF/wtf/posix/FileSystemPOSIX.cpp:116 > +PlatformFileHandle createFile(const String& path, FileOpenMode mode, FileAccessPermission permission)
Can't exclusivness just be another parameter for openFile? Seems unnecessary to copy the whole function. Also your openFile can still create files and name createFile doesn't really communicate the difference.
Christopher Reid
Comment 36
2020-02-25 00:49:03 PST
Created
attachment 391632
[details]
Patch Added onlyCreateFile parameter to openFile instead of using a new function.
Christopher Reid
Comment 37
2020-02-25 14:18:06 PST
Created
attachment 391685
[details]
patch Ensure the salt file is deleted if it exists but doesn't match the needed salt size.
Yusuke Suzuki
Comment 38
2020-02-25 17:25:59 PST
Comment on
attachment 391685
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=391685&action=review
r=me
> Source/WTF/ChangeLog:16 > + Added onlyCreateFile flag to openFile which causes openFile to fail if the file already exists.
We should name this flag as `failIfFileExists`
> Source/WebKit/NetworkProcess/cache/NetworkCacheData.cpp:43 > + auto handle = FileSystem::openFile(path, FileSystem::FileOpenMode::ReadWrite, FileSystem::FileAccessPermission::User, true);
Let's not pass boolean directly, it is hard to read what this bool means. constexpr bool failIfFileExists = true; auto handle = FileSystem::openFile(path, ..., failIfFileExists); is better.
Christopher Reid
Comment 39
2020-02-26 10:52:43 PST
Created
attachment 391756
[details]
Patch for landing
Christopher Reid
Comment 40
2020-02-26 10:57:59 PST
Created
attachment 391757
[details]
Patch for landing
WebKit Commit Bot
Comment 41
2020-02-26 11:28:19 PST
Comment on
attachment 391757
[details]
Patch for landing Rejecting
attachment 391757
[details]
from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-02', 'validate-changelog', '--check-oops', '--non-interactive', 391757, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit ChangeLog entry in LayoutTests/ChangeLog contains OOPS!. Full output:
https://webkit-queues.webkit.org/results/13329377
Christopher Reid
Comment 42
2020-02-26 13:05:15 PST
Created
attachment 391772
[details]
Patch for landing
WebKit Commit Bot
Comment 43
2020-02-26 13:40:01 PST
Comment on
attachment 391772
[details]
Patch for landing Rejecting
attachment 391772
[details]
from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-01', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', 391772, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit Logging in as
commit-queue@webkit.org
... Fetching:
https://bugs.webkit.org/attachment.cgi?id=391772&action=edit
Fetching:
https://bugs.webkit.org/show_bug.cgi?id=197684
&ctype=xml&excludefield=attachmentdata Processing 1 patch from 1 bug. Updating working directory Processing patch 391772 from
bug 197684
. Fetching:
https://bugs.webkit.org/attachment.cgi?id=391772
Failed to run "['git', 'svn', 'dcommit', '--rmdir']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit Committing to
http://svn.webkit.org/repository/webkit/trunk
... M LayoutTests/ChangeLog M LayoutTests/platform/wincairo/TestExpectations M Source/WTF/ChangeLog M Source/WTF/wtf/FileSystem.cpp M Source/WTF/wtf/FileSystem.h M Source/WTF/wtf/glib/FileSystemGlib.cpp M Source/WTF/wtf/posix/FileSystemPOSIX.cpp M Source/WTF/wtf/win/FileSystemWin.cpp M Source/WTF/wtf/win/PathWalker.cpp M Source/WebKit/ChangeLog M Source/WebKit/NetworkProcess/NetworkProcess.cpp M Source/WebKit/NetworkProcess/cache/NetworkCacheData.cpp M Source/WebKit/NetworkProcess/cache/NetworkCacheData.h M Source/WebKit/NetworkProcess/cache/NetworkCacheDataCocoa.mm M Source/WebKit/NetworkProcess/cache/NetworkCacheDataCurl.cpp M Source/WebKit/NetworkProcess/cache/NetworkCacheDataSoup.cpp M Source/WebKit/NetworkProcess/cache/NetworkCacheFileSystem.cpp M Tools/ChangeLog M Tools/TestWebKitAPI/Tests/WTF/FileSystem.cpp ERROR from SVN: Merge conflict during commit: Conflict at '/trunk/LayoutTests/ChangeLog' W: c1bfafc7aabfe735fbd0fdaeed79acbf8a3a31be and refs/remotes/origin/master differ, using rebase: :040000 040000 3715dea03ca78607882c1c315dd41b063fb3cfd7 148ef925334bff92d196d535b0dac66bb1037bda M LayoutTests :040000 040000 82adc380b74dda0797ee354f6e8bade45a6ddd51 8eee6c7b770d71aabbb3cc5bab7b21d43e8dbbeb M Source :040000 040000 57674841b68c9058d5d4bbfa659f2fbd7367d9b4 adfcec4e4cae19a6159741b7cffdddced27e95ec M Tools Current branch master is up to date. ERROR: Not all changes have been committed into SVN, however the committed ones (if any) seem to be successfully integrated into the working tree. Please see the above messages for details. Failed to run "['git', 'svn', 'dcommit', '--rmdir']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit Committing to
http://svn.webkit.org/repository/webkit/trunk
... M LayoutTests/ChangeLog M LayoutTests/platform/wincairo/TestExpectations M Source/WTF/ChangeLog M Source/WTF/wtf/FileSystem.cpp M Source/WTF/wtf/FileSystem.h M Source/WTF/wtf/glib/FileSystemGlib.cpp M Source/WTF/wtf/posix/FileSystemPOSIX.cpp M Source/WTF/wtf/win/FileSystemWin.cpp M Source/WTF/wtf/win/PathWalker.cpp M Source/WebKit/ChangeLog M Source/WebKit/NetworkProcess/NetworkProcess.cpp M Source/WebKit/NetworkProcess/cache/NetworkCacheData.cpp M Source/WebKit/NetworkProcess/cache/NetworkCacheData.h M Source/WebKit/NetworkProcess/cache/NetworkCacheDataCocoa.mm M Source/WebKit/NetworkProcess/cache/NetworkCacheDataCurl.cpp M Source/WebKit/NetworkProcess/cache/NetworkCacheDataSoup.cpp M Source/WebKit/NetworkProcess/cache/NetworkCacheFileSystem.cpp M Tools/ChangeLog M Tools/TestWebKitAPI/Tests/WTF/FileSystem.cpp ERROR from SVN: Merge conflict during commit: Conflict at '/trunk/LayoutTests/ChangeLog' W: c1bfafc7aabfe735fbd0fdaeed79acbf8a3a31be and refs/remotes/origin/master differ, using rebase: :040000 040000 3715dea03ca78607882c1c315dd41b063fb3cfd7 148ef925334bff92d196d535b0dac66bb1037bda M LayoutTests :040000 040000 82adc380b74dda0797ee354f6e8bade45a6ddd51 8eee6c7b770d71aabbb3cc5bab7b21d43e8dbbeb M Source :040000 040000 57674841b68c9058d5d4bbfa659f2fbd7367d9b4 adfcec4e4cae19a6159741b7cffdddced27e95ec M Tools Current branch master is up to date. ERROR: Not all changes have been committed into SVN, however the committed ones (if any) seem to be successfully integrated into the working tree. Please see the above messages for details. Failed to run "['git', 'svn', 'dcommit', '--rmdir']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit Updating OpenSource From
https://git.webkit.org/git/WebKit
3e82a3cc5f3..6e9734c7a4b master -> origin/master Partial-rebuilding .git/svn/refs/remotes/origin/master/.rev_map.268f45cc-cd09-0410-ab3c-d52691b4dbfc ... Currently at 257504 = 3e82a3cc5f3052c3efd94f1fcd7e5a415cff6081
r257505
= a637395bea617d4b228aee28c27901a985d367d9
r257506
= 527e95c4d5abfe1debc954754e724863585b06b0
r257507
= c79f943807fc8c0263328fe23f54573a3f130024
r257508
= 6e9734c7a4b54261fe14c29ef4c46c599eb2f656 Done rebuilding .git/svn/refs/remotes/origin/master/.rev_map.268f45cc-cd09-0410-ab3c-d52691b4dbfc First, rewinding head to replay your work on top of it... Fast-forwarded master to refs/remotes/origin/master. Total errors found: 0 in 1 files Full output:
https://webkit-queues.webkit.org/results/13329457
Christopher Reid
Comment 44
2020-02-26 13:57:59 PST
Created
attachment 391776
[details]
Patch for landing
WebKit Commit Bot
Comment 45
2020-02-26 14:41:45 PST
Comment on
attachment 391776
[details]
Patch for landing Clearing flags on attachment: 391776 Committed
r257518
: <
https://trac.webkit.org/changeset/257518
>
WebKit Commit Bot
Comment 46
2020-02-26 14:41:48 PST
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug