225307 2021-05-03 08:09:43 -0700 Restore pre-r276879 behavior for FileSystem::moveFile() 2021-05-03 16:54:14 -0700 1 1 1 Unclassified WebKit Web Template Framework WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=225255 InRadar P2 Normal --- 1 cdumez cdumez benjamin cmarcelo darin ews-watchlist ggaren sam webkit-bug-importer oldest_to_newest 1756181 0 cdumez 2021-05-03 08:09:43 -0700 Restore pre-r276879 behavior for FileSystem::moveFile(). In particular, FileSystem::moveFile() used to support moving a file across different volumes. 1756186 1 427562 cdumez 2021-05-03 08:28:25 -0700 Created attachment 427562 Patch 1756267 2 427562 darin 2021-05-03 12:15:20 -0700 Comment on attachment 427562 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=427562&action=review > Source/WTF/wtf/FileSystem.cpp:545 > + std::filesystem::copy(fsOldPath, fsNewPath, std::filesystem::copy_options::overwrite_existing, ec); I think this may still be different behavior from the old code on Apple platforms. Does it copy the metadata too, or just the data in the file? > Source/WTF/wtf/FileSystem.cpp:548 > + return std::filesystem::remove(fsOldPath, ec); This could be a non-empty directory, so then I think we’d need remove_all, right? Is it desired behavior that if the remove fails, we leave the second copy behind and return false, but there is no indication that there are now two copies? We could attempt to delete the copy, if that’s the semantic we want. But then we might delete all of the copy and part of the original maybe? 1756273 3 cdumez 2021-05-03 12:32:13 -0700 (In reply to Darin Adler from comment #2) > Comment on attachment 427562 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=427562&action=review > > > Source/WTF/wtf/FileSystem.cpp:545 > > + std::filesystem::copy(fsOldPath, fsNewPath, std::filesystem::copy_options::overwrite_existing, ec); > > I think this may still be different behavior from the old code on Apple > platforms. Does it copy the metadata too, or just the data in the file? All I see in the Apple documentation is: """ If the source and destination of the move operation are not on the same volume, this method copies the item first and then removes it from its current location. This behavior may trigger additional delegate notifications related to copying and removing individual items. """ I will try it out and check. > > > Source/WTF/wtf/FileSystem.cpp:548 > > + return std::filesystem::remove(fsOldPath, ec); > > This could be a non-empty directory, so then I think we’d need remove_all, > right? Indeed, that is a good point. I'll fix. > Is it desired behavior that if the remove fails, we leave the second copy > behind and return false, but there is no indication that there are now two > copies? We could attempt to delete the copy, if that’s the semantic we want. > But then we might delete all of the copy and part of the original maybe? This is what I *thought* was the best behavior. This is very edge-casy but we could indeed also try and restore original state if deleting the original file fails. 1756274 4 cdumez 2021-05-03 12:41:04 -0700 (In reply to Chris Dumez from comment #3) > (In reply to Darin Adler from comment #2) > > Comment on attachment 427562 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=427562&action=review > > > > > Source/WTF/wtf/FileSystem.cpp:545 > > > + std::filesystem::copy(fsOldPath, fsNewPath, std::filesystem::copy_options::overwrite_existing, ec); > > > > I think this may still be different behavior from the old code on Apple > > platforms. Does it copy the metadata too, or just the data in the file? What kind of metadata were you concerned about? Things like the files permissions (readable/writeable..) or other things too? (maybe creation time / last modified?). > > All I see in the Apple documentation is: > """ > If the source and destination of the move operation are not on the same > volume, this method copies the item first and then removes it from its > current location. This behavior may trigger additional delegate > notifications related to copying and removing individual items. > """ > > I will try it out and check. > > > > > > Source/WTF/wtf/FileSystem.cpp:548 > > > + return std::filesystem::remove(fsOldPath, ec); > > > > This could be a non-empty directory, so then I think we’d need remove_all, > > right? > > Indeed, that is a good point. I'll fix. > > > Is it desired behavior that if the remove fails, we leave the second copy > > behind and return false, but there is no indication that there are now two > > copies? We could attempt to delete the copy, if that’s the semantic we want. > > But then we might delete all of the copy and part of the original maybe? > > This is what I *thought* was the best behavior. This is very edge-casy but > we could indeed also try and restore original state if deleting the original > file fails. For what it's worth [NSFileManager moveItemAtURL:], which is what we were using on macOS, does not remove the copy if the removal of the source fails. It merely reports an error in this case. So the behavior seems similar to what I implemented. 1756280 5 427562 darin 2021-05-03 12:51:21 -0700 Comment on attachment 427562 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=427562&action=review >>>> Source/WTF/wtf/FileSystem.cpp:545 >>>> + std::filesystem::copy(fsOldPath, fsNewPath, std::filesystem::copy_options::overwrite_existing, ec); >>> >>> I think this may still be different behavior from the old code on Apple platforms. Does it copy the metadata too, or just the data in the file? >> >> All I see in the Apple documentation is: >> """ >> If the source and destination of the move operation are not on the same volume, this method copies the item first and then removes it from its current location. This behavior may trigger additional delegate notifications related to copying and removing individual items. >> """ >> >> I will try it out and check. > > What kind of metadata were you concerned about? Things like the files permissions (readable/writeable..) or other things too? (maybe creation time / last modified?). Since I’m a such an old school Mac person I think of likely-long-obsolete things like "resource forks", file type and creator. There is this general "extended file attributes" category that is what the xattr tool manipulates. Not sure off hand what purposes this is used for. 1756282 6 427562 darin 2021-05-03 12:54:19 -0700 Comment on attachment 427562 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=427562&action=review >>>>> Source/WTF/wtf/FileSystem.cpp:545 >>>>> + std::filesystem::copy(fsOldPath, fsNewPath, std::filesystem::copy_options::overwrite_existing, ec); >>>> >>>> I think this may still be different behavior from the old code on Apple platforms. Does it copy the metadata too, or just the data in the file? >>> >>> All I see in the Apple documentation is: >>> """ >>> If the source and destination of the move operation are not on the same volume, this method copies the item first and then removes it from its current location. This behavior may trigger additional delegate notifications related to copying and removing individual items. >>> """ >>> >>> I will try it out and check. >> >> What kind of metadata were you concerned about? Things like the files permissions (readable/writeable..) or other things too? (maybe creation time / last modified?). > > Since I’m a such an old school Mac person I think of likely-long-obsolete things like "resource forks", file type and creator. There is this general "extended file attributes" category that is what the xattr tool manipulates. Not sure off hand what purposes this is used for. On example is probably the download metadata that is used by Gatekeeper to tell people where a previously unopened file was downloaded from. But some of this is done automatically by the OS with no way to bypass I think. Trying to get all these things right is the reason programmers use the provided OS level file copying function instead of writing our own. The POSIX level one is copyfile, I think. It has flags to control this: COPYFILE_ACL, COPYFILE_STAT, and COPYFILE_XATTR. I have no idea if these matter for the cases we use. 1756310 7 cdumez 2021-05-03 13:45:59 -0700 (In reply to Darin Adler from comment #6) > Comment on attachment 427562 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=427562&action=review > > >>>>> Source/WTF/wtf/FileSystem.cpp:545 > >>>>> + std::filesystem::copy(fsOldPath, fsNewPath, std::filesystem::copy_options::overwrite_existing, ec); > >>>> > >>>> I think this may still be different behavior from the old code on Apple platforms. Does it copy the metadata too, or just the data in the file? > >>> > >>> All I see in the Apple documentation is: > >>> """ > >>> If the source and destination of the move operation are not on the same volume, this method copies the item first and then removes it from its current location. This behavior may trigger additional delegate notifications related to copying and removing individual items. > >>> """ > >>> > >>> I will try it out and check. > >> > >> What kind of metadata were you concerned about? Things like the files permissions (readable/writeable..) or other things too? (maybe creation time / last modified?). > > > > Since I’m a such an old school Mac person I think of likely-long-obsolete things like "resource forks", file type and creator. There is this general "extended file attributes" category that is what the xattr tool manipulates. Not sure off hand what purposes this is used for. > > On example is probably the download metadata that is used by Gatekeeper to > tell people where a previously unopened file was downloaded from. But some > of this is done automatically by the OS with no way to bypass I think. > > Trying to get all these things right is the reason programmers use the > provided OS level file copying function instead of writing our own. The > POSIX level one is copyfile, I think. It has flags to control this: > COPYFILE_ACL, COPYFILE_STAT, and COPYFILE_XATTR. > > I have no idea if these matter for the cases we use. I see, there is a std::filesystem::copy_file() which does copy the attributes over. However, it only copies a single regular file. 1756311 8 427598 cdumez 2021-05-03 13:47:19 -0700 Created attachment 427598 Patch 1756313 9 cdumez 2021-05-03 13:50:57 -0700 (In reply to Chris Dumez from comment #7) > (In reply to Darin Adler from comment #6) > > Comment on attachment 427562 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=427562&action=review > > > > >>>>> Source/WTF/wtf/FileSystem.cpp:545 > > >>>>> + std::filesystem::copy(fsOldPath, fsNewPath, std::filesystem::copy_options::overwrite_existing, ec); > > >>>> > > >>>> I think this may still be different behavior from the old code on Apple platforms. Does it copy the metadata too, or just the data in the file? > > >>> > > >>> All I see in the Apple documentation is: > > >>> """ > > >>> If the source and destination of the move operation are not on the same volume, this method copies the item first and then removes it from its current location. This behavior may trigger additional delegate notifications related to copying and removing individual items. > > >>> """ > > >>> > > >>> I will try it out and check. > > >> > > >> What kind of metadata were you concerned about? Things like the files permissions (readable/writeable..) or other things too? (maybe creation time / last modified?). > > > > > > Since I’m a such an old school Mac person I think of likely-long-obsolete things like "resource forks", file type and creator. There is this general "extended file attributes" category that is what the xattr tool manipulates. Not sure off hand what purposes this is used for. > > > > On example is probably the download metadata that is used by Gatekeeper to > > tell people where a previously unopened file was downloaded from. But some > > of this is done automatically by the OS with no way to bypass I think. > > > > Trying to get all these things right is the reason programmers use the > > provided OS level file copying function instead of writing our own. The > > POSIX level one is copyfile, I think. It has flags to control this: > > COPYFILE_ACL, COPYFILE_STAT, and COPYFILE_XATTR. > > > > I have no idea if these matter for the cases we use. > > I see, there is a std::filesystem::copy_file() which does copy the > attributes over. However, it only copies a single regular file. Reading the documentation for std::filesystem::copy() more closely, I see that it will end up calling std::filesystem::copy_file() for each file so it will indeed copy both the content and the attributes. 1756372 10 ews-feeder 2021-05-03 16:53:31 -0700 Committed r276936 (237272@main): <https://commits.webkit.org/237272@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 427598. 1756373 11 webkit-bug-importer 2021-05-03 16:54:14 -0700 <rdar://problem/77478629> 427562 2021-05-03 08:28:25 -0700 2021-05-03 13:47:17 -0700 Patch bug-225307-20210503082824.patch text/plain 4931 cdumez U3VidmVyc2lvbiBSZXZpc2lvbjogMjc2ODg4CmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL0NoYW5n ZUxvZyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCmluZGV4IDQ4MTVlODQzY2I1OTI0YmI2NjQ0MWEz NzJjZjRhNjU4NzQ4YmZhYjAuLjBhNjg2OGViYjk1MjQ4YzU2Zjk1MGRjOTI5N2ZlNzk1ZGQ3MTRh NTMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hh bmdlTG9nCkBAIC0xLDMgKzEsMjAgQEAKKzIwMjEtMDUtMDMgIENocmlzIER1bWV6ICA8Y2R1bWV6 QGFwcGxlLmNvbT4KKworICAgICAgICBSZXN0b3JlIHByZS1yMjc2ODc5IGJlaGF2aW9yIGZvciBG aWxlU3lzdGVtOjptb3ZlRmlsZSgpCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3No b3dfYnVnLmNnaT9pZD0yMjUzMDcKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMh KS4KKworICAgICAgICBVcGRhdGUgRmlsZVN5c3RlbTo6bW92ZUZpbGUoKSBzbyB0aGF0IGl0IG5v dyBzdXBwb3J0cyBhZ2FpbiBtb3ZpbmcgYSBmaWxlIGFjcm9zcyBkaWZmZXJlbnQKKyAgICAgICAg dm9sdW1lcyBieSBjb3B5aW5nIHRoZSBmaWxlIG92ZXIgYW5kIHRoZW4gZGVsZXRpbmcgdGhlIHNv dXJjZSBmaWxlLgorCisgICAgICAgIEkgaGF2ZSB2ZXJpZmllZCBsb2NhbGx5IHRoYXQgdGhlIGZ1 bmN0aW9uIGlzIG5vdyBhYmxlIHRvIG1vdmUgYSBmaWxlIHRvIGEgZGlmZmVyZW50IHZvbHVtZXMu CisgICAgICAgIFNhZGx5LCBJIGRvbid0IHRoaW5rIGhhdmluZyBhbiBBUEkgdGVzdCBpcyBmZWFz aWJsZSBoZXJlIGFzIGl0IHJlcXVpcmVzIHByZS1kZXRlcm1pbmVkCisgICAgICAgIHZvbHVtZXMg dG8gYmUgYXZhaWxhYmxlLgorCisgICAgICAgICogd3RmL0ZpbGVTeXN0ZW0uY3BwOgorICAgICAg ICAoV1RGOjpGaWxlU3lzdGVtSW1wbDo6bW92ZUZpbGUpOgorCiAyMDIxLTA1LTAyICBDaHJpcyBE dW1leiAgPGNkdW1lekBhcHBsZS5jb20+CiAKICAgICAgICAgUmVzdG9yZSBwcmUtcjI3Njg3OSBi ZWhhdmlvciBmb3IgRmlsZVN5c3RlbTo6ZGVsZXRlRmlsZSgpIGFuZCBGaWxlU3lzdGVtOjpkZWxl dGVFbXB0eURpcmVjdG9yeSgpCmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL3d0Zi9GaWxlU3lzdGVt LmNwcCBiL1NvdXJjZS9XVEYvd3RmL0ZpbGVTeXN0ZW0uY3BwCmluZGV4IDFmY2RiY2Q2ZjExNTNk NzYzNzM1YjhiY2I3NmQ4ODc2Y2U0ODU2YWIuLjE4MjUyZDM3Zjk0YTNjMDliZDFhODAyNWEwODQ2 YmI3NTNkNmUyZDcgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvd3RmL0ZpbGVTeXN0ZW0uY3BwCisr KyBiL1NvdXJjZS9XVEYvd3RmL0ZpbGVTeXN0ZW0uY3BwCkBAIC01MzIsOSArNTMyLDIwIEBAIGJv b2wgZGVsZXRlRW1wdHlEaXJlY3RvcnkoY29uc3QgU3RyaW5nJiBwYXRoKQogCiBib29sIG1vdmVG aWxlKGNvbnN0IFN0cmluZyYgb2xkUGF0aCwgY29uc3QgU3RyaW5nJiBuZXdQYXRoKQogeworICAg IHN0ZDo6ZmlsZXN5c3RlbTo6cGF0aCBmc09sZFBhdGggPSBmaWxlU3lzdGVtUmVwcmVzZW50YXRp b24ob2xkUGF0aCkuZGF0YSgpOworICAgIHN0ZDo6ZmlsZXN5c3RlbTo6cGF0aCBmc05ld1BhdGgg PSBmaWxlU3lzdGVtUmVwcmVzZW50YXRpb24obmV3UGF0aCkuZGF0YSgpOworCiAgICAgc3RkOjpl cnJvcl9jb2RlIGVjOwotICAgIHN0ZDo6ZmlsZXN5c3RlbTo6cmVuYW1lKGZpbGVTeXN0ZW1SZXBy ZXNlbnRhdGlvbihvbGRQYXRoKS5kYXRhKCksIGZpbGVTeXN0ZW1SZXByZXNlbnRhdGlvbihuZXdQ YXRoKS5kYXRhKCksIGVjKTsKLSAgICByZXR1cm4gIWVjOworICAgIHN0ZDo6ZmlsZXN5c3RlbTo6 cmVuYW1lKGZzT2xkUGF0aCwgZnNOZXdQYXRoLCBlYyk7CisgICAgaWYgKCFlYykKKyAgICAgICAg cmV0dXJuIHRydWU7CisKKyAgICAvLyBGYWxsIGJhY2sgdG8gY29weWluZyBhbmQgdGhlbiBkZWxl dGluZyBzb3VyY2UgYXMgcmVuYW1lKCkgZG9lcyBub3Qgd29yayBhY3Jvc3Mgdm9sdW1lcy4KKyAg ICBlYyA9IHsgfTsKKyAgICBzdGQ6OmZpbGVzeXN0ZW06OmNvcHkoZnNPbGRQYXRoLCBmc05ld1Bh dGgsIHN0ZDo6ZmlsZXN5c3RlbTo6Y29weV9vcHRpb25zOjpvdmVyd3JpdGVfZXhpc3RpbmcsIGVj KTsKKyAgICBpZiAoZWMpCisgICAgICAgIHJldHVybiBmYWxzZTsKKyAgICByZXR1cm4gc3RkOjpm aWxlc3lzdGVtOjpyZW1vdmUoZnNPbGRQYXRoLCBlYyk7CiB9CiAKIGJvb2wgZ2V0RmlsZVNpemUo Y29uc3QgU3RyaW5nJiBwYXRoLCBsb25nIGxvbmcmIHJlc3VsdCkKZGlmZiAtLWdpdCBhL1Rvb2xz L0NoYW5nZUxvZyBiL1Rvb2xzL0NoYW5nZUxvZwppbmRleCBjZWQzZTAwYWVlODVmMWRlNTJjMDg3 MTQ3NDY5ZjQ5YzdiZGEzOWFmLi43NjEwY2M1MTM3YTc5ZDI5ZDM0ZTNiNjBmMTE5YjBkYWE5NTky MDE3IDEwMDY0NAotLS0gYS9Ub29scy9DaGFuZ2VMb2cKKysrIGIvVG9vbHMvQ2hhbmdlTG9nCkBA IC0xLDMgKzEsMTYgQEAKKzIwMjEtMDUtMDMgIENocmlzIER1bWV6ICA8Y2R1bWV6QGFwcGxlLmNv bT4KKworICAgICAgICBSZXN0b3JlIHByZS1yMjc2ODc5IGJlaGF2aW9yIGZvciBGaWxlU3lzdGVt Ojptb3ZlRmlsZSgpCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNn aT9pZD0yMjUzMDcKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAg ICAgICBBZGQgQVBJIHRlc3QgdG8gbWFrZSBzdXJlIHRoYXQgRmlsZVN5c3RlbTo6bW92ZUZpbGUo KSBpcyBhYmxlIHRvIG1vdmUgZGlyZWN0b3JpZXMgc2luY2UgdGhpcworICAgICAgICB3YXMgdGhl IGNhc2UgcHJpb3IgdG8gcjI3Njg3OS4KKworICAgICAgICAqIFRlc3RXZWJLaXRBUEkvVGVzdHMv V1RGL0ZpbGVTeXN0ZW0uY3BwOgorICAgICAgICAoVGVzdFdlYktpdEFQSTo6VEVTVF9GKToKKwog MjAyMS0wNS0wMiAgQ2hyaXMgRHVtZXogIDxjZHVtZXpAYXBwbGUuY29tPgogCiAgICAgICAgIFJl c3RvcmUgcHJlLXIyNzY4NzkgYmVoYXZpb3IgZm9yIEZpbGVTeXN0ZW06OmRlbGV0ZUZpbGUoKSBh bmQgRmlsZVN5c3RlbTo6ZGVsZXRlRW1wdHlEaXJlY3RvcnkoKQpkaWZmIC0tZ2l0IGEvVG9vbHMv VGVzdFdlYktpdEFQSS9UZXN0cy9XVEYvRmlsZVN5c3RlbS5jcHAgYi9Ub29scy9UZXN0V2ViS2l0 QVBJL1Rlc3RzL1dURi9GaWxlU3lzdGVtLmNwcAppbmRleCAwZWNkYTliOWU2NjhhMmRiMDBlYWU2 OTQwMmE1NDI1NmNiYTIyOTU4Li44YjczYWYxZTg4ZGFmMmJiZWRlNjI5MzZiYWM4N2ZjMmU0ZDg2 ODhjIDEwMDY0NAotLS0gYS9Ub29scy9UZXN0V2ViS2l0QVBJL1Rlc3RzL1dURi9GaWxlU3lzdGVt LmNwcAorKysgYi9Ub29scy9UZXN0V2ViS2l0QVBJL1Rlc3RzL1dURi9GaWxlU3lzdGVtLmNwcApA QCAtMzI4LDYgKzMyOCwzMiBAQCBURVNUX0YoRmlsZVN5c3RlbVRlc3QsIG1vdmVGaWxlT3Zlcndy aXRlc0Rlc3RpbmF0aW9uKQogICAgIEVYUEVDVF9HVChmaWxlU2l6ZSwgMCk7CiB9CiAKK1RFU1Rf RihGaWxlU3lzdGVtVGVzdCwgbW92ZURpcmVjdG9yeSkKK3sKKyAgICBGaWxlU3lzdGVtOjpQbGF0 Zm9ybUZpbGVIYW5kbGUgdGVtcG9yYXJ5RmlsZTsKKyAgICBhdXRvIHRlbXBvcmFyeVRlc3RGb2xk ZXIgPSBGaWxlU3lzdGVtOjpvcGVuVGVtcG9yYXJ5RmlsZSgibW92ZURpcmVjdG9yeVRlc3QiLCB0 ZW1wb3JhcnlGaWxlKTsKKyAgICBGaWxlU3lzdGVtOjpjbG9zZUZpbGUodGVtcG9yYXJ5RmlsZSk7 CisKKyAgICBFWFBFQ1RfVFJVRShGaWxlU3lzdGVtOjpkZWxldGVGaWxlKHRlbXBvcmFyeVRlc3RG b2xkZXIpKTsKKyAgICBFWFBFQ1RfVFJVRShGaWxlU3lzdGVtOjptYWtlQWxsRGlyZWN0b3JpZXMo dGVtcG9yYXJ5VGVzdEZvbGRlcikpOworICAgIGF1dG8gdGVzdEZpbGVQYXRoID0gRmlsZVN5c3Rl bTo6cGF0aEJ5QXBwZW5kaW5nQ29tcG9uZW50KHRlbXBvcmFyeVRlc3RGb2xkZXIsICJ0ZXN0Rmls ZSIpOworICAgIGF1dG8gZmlsZUhhbmRsZSA9IEZpbGVTeXN0ZW06Om9wZW5GaWxlKHRlc3RGaWxl UGF0aCwgRmlsZVN5c3RlbTo6RmlsZU9wZW5Nb2RlOjpXcml0ZSk7CisgICAgRmlsZVN5c3RlbTo6 d3JpdGVUb0ZpbGUoZmlsZUhhbmRsZSwgRmlsZVN5c3RlbVRlc3REYXRhLCBzdHJsZW4oRmlsZVN5 c3RlbVRlc3REYXRhKSk7CisgICAgRmlsZVN5c3RlbTo6Y2xvc2VGaWxlKGZpbGVIYW5kbGUpOwor CisgICAgRVhQRUNUX1RSVUUoRmlsZVN5c3RlbTo6ZmlsZUV4aXN0cyh0ZXN0RmlsZVBhdGgpKTsK KworICAgIGF1dG8gZGVzdGluYXRpb25QYXRoID0gRmlsZVN5c3RlbTo6cGF0aEJ5QXBwZW5kaW5n Q29tcG9uZW50KHRlbXBFbXB0eUZvbGRlclBhdGgoKSwgIm1vdmVEaXJlY3RvcnlUZXN0Iik7Cisg ICAgRVhQRUNUX1RSVUUoRmlsZVN5c3RlbTo6bW92ZUZpbGUodGVtcG9yYXJ5VGVzdEZvbGRlciwg ZGVzdGluYXRpb25QYXRoKSk7CisgICAgRVhQRUNUX0ZBTFNFKEZpbGVTeXN0ZW06OmZpbGVFeGlz dHModGVtcG9yYXJ5VGVzdEZvbGRlcikpOworICAgIEVYUEVDVF9GQUxTRShGaWxlU3lzdGVtOjpm aWxlRXhpc3RzKHRlc3RGaWxlUGF0aCkpOworICAgIEVYUEVDVF9UUlVFKEZpbGVTeXN0ZW06OmZp bGVFeGlzdHMoZGVzdGluYXRpb25QYXRoKSk7CisgICAgRVhQRUNUX1RSVUUoRmlsZVN5c3RlbTo6 ZmlsZUV4aXN0cyhGaWxlU3lzdGVtOjpwYXRoQnlBcHBlbmRpbmdDb21wb25lbnQoZGVzdGluYXRp b25QYXRoLCAidGVzdEZpbGUiKSkpOworCisgICAgRVhQRUNUX0ZBTFNFKEZpbGVTeXN0ZW06OmRl bGV0ZUVtcHR5RGlyZWN0b3J5KGRlc3RpbmF0aW9uUGF0aCkpOworICAgIEVYUEVDVF9UUlVFKEZp bGVTeXN0ZW06OmZpbGVFeGlzdHMoZGVzdGluYXRpb25QYXRoKSk7Cit9CisKIFRFU1RfRihGaWxl U3lzdGVtVGVzdCwgZ2V0RmlsZVNpemUpCiB7CiAgICAgRVhQRUNUX1RSVUUoRmlsZVN5c3RlbTo6 ZmlsZUV4aXN0cyh0ZW1wRmlsZVBhdGgoKSkpOwo= 427598 2021-05-03 13:47:19 -0700 2021-05-03 16:53:32 -0700 Patch bug-225307-20210503134718.patch text/plain 4912 cdumez U3VidmVyc2lvbiBSZXZpc2lvbjogMjc2OTIyCmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL0NoYW5n ZUxvZyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCmluZGV4IGY1ZDYxNGE4NzI3YTY4OGNhMTQxN2Q5 YWNkNGYwMDYxZDNjZGZhM2QuLmIwN2E4NDBlYWM5NWFlYjk5MzQ4YWIyZmRjZjU3NzdiYWFjNjU1 ZjUgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hh bmdlTG9nCkBAIC0xLDMgKzEsMjAgQEAKKzIwMjEtMDUtMDMgIENocmlzIER1bWV6ICA8Y2R1bWV6 QGFwcGxlLmNvbT4KKworICAgICAgICBSZXN0b3JlIHByZS1yMjc2ODc5IGJlaGF2aW9yIGZvciBG aWxlU3lzdGVtOjptb3ZlRmlsZSgpCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3No b3dfYnVnLmNnaT9pZD0yMjUzMDcKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMh KS4KKworICAgICAgICBVcGRhdGUgRmlsZVN5c3RlbTo6bW92ZUZpbGUoKSBzbyB0aGF0IGl0IG5v dyBzdXBwb3J0cyBhZ2FpbiBtb3ZpbmcgYSBmaWxlIGFjcm9zcyBkaWZmZXJlbnQKKyAgICAgICAg dm9sdW1lcyBieSBjb3B5aW5nIHRoZSBmaWxlIG92ZXIgYW5kIHRoZW4gZGVsZXRpbmcgdGhlIHNv dXJjZSBmaWxlLgorCisgICAgICAgIEkgaGF2ZSB2ZXJpZmllZCBsb2NhbGx5IHRoYXQgdGhlIGZ1 bmN0aW9uIGlzIG5vdyBhYmxlIHRvIG1vdmUgYSBmaWxlIHRvIGEgZGlmZmVyZW50IHZvbHVtZXMu CisgICAgICAgIFNhZGx5LCBJIGRvbid0IHRoaW5rIGhhdmluZyBhbiBBUEkgdGVzdCBpcyBmZWFz aWJsZSBoZXJlIGFzIGl0IHJlcXVpcmVzIHByZS1kZXRlcm1pbmVkCisgICAgICAgIHZvbHVtZXMg dG8gYmUgYXZhaWxhYmxlLgorCisgICAgICAgICogd3RmL0ZpbGVTeXN0ZW0uY3BwOgorICAgICAg ICAoV1RGOjpGaWxlU3lzdGVtSW1wbDo6bW92ZUZpbGUpOgorCiAyMDIxLTA1LTAzICBEaWVnbyBQ aW5vIEdhcmNpYSAgPGRwaW5vQGlnYWxpYS5jb20+CiAKICAgICAgICAgW0dMSUJdIFJFR1JFU1NJ T04ocjI3Njg3OSk6IFNldmVyYWwgdGVzdHMgYXJlIGNyYXNoaW5nIG9yIGZhaWxpbmcKZGlmZiAt LWdpdCBhL1NvdXJjZS9XVEYvd3RmL0ZpbGVTeXN0ZW0uY3BwIGIvU291cmNlL1dURi93dGYvRmls ZVN5c3RlbS5jcHAKaW5kZXggODE2ZmFkZmFmOTEzODNlYjYyZmU4MTY5YTFhNjBiMWQ0ZGU0NmY1 Yi4uZjdkNjc0OWNjOWViZTVjOTE5N2JkMDg4MDBhZDY4MjkyODFmMjlkYyAxMDA2NDQKLS0tIGEv U291cmNlL1dURi93dGYvRmlsZVN5c3RlbS5jcHAKKysrIGIvU291cmNlL1dURi93dGYvRmlsZVN5 c3RlbS5jcHAKQEAgLTUzMiw5ICs1MzIsMjAgQEAgYm9vbCBkZWxldGVFbXB0eURpcmVjdG9yeShj b25zdCBTdHJpbmcmIHBhdGgpCiAKIGJvb2wgbW92ZUZpbGUoY29uc3QgU3RyaW5nJiBvbGRQYXRo LCBjb25zdCBTdHJpbmcmIG5ld1BhdGgpCiB7CisgICAgc3RkOjpmaWxlc3lzdGVtOjpwYXRoIGZz T2xkUGF0aCA9IGZpbGVTeXN0ZW1SZXByZXNlbnRhdGlvbihvbGRQYXRoKS5kYXRhKCk7CisgICAg c3RkOjpmaWxlc3lzdGVtOjpwYXRoIGZzTmV3UGF0aCA9IGZpbGVTeXN0ZW1SZXByZXNlbnRhdGlv bihuZXdQYXRoKS5kYXRhKCk7CisKICAgICBzdGQ6OmVycm9yX2NvZGUgZWM7Ci0gICAgc3RkOjpm aWxlc3lzdGVtOjpyZW5hbWUoZmlsZVN5c3RlbVJlcHJlc2VudGF0aW9uKG9sZFBhdGgpLmRhdGEo KSwgZmlsZVN5c3RlbVJlcHJlc2VudGF0aW9uKG5ld1BhdGgpLmRhdGEoKSwgZWMpOwotICAgIHJl dHVybiAhZWM7CisgICAgc3RkOjpmaWxlc3lzdGVtOjpyZW5hbWUoZnNPbGRQYXRoLCBmc05ld1Bh dGgsIGVjKTsKKyAgICBpZiAoIWVjKQorICAgICAgICByZXR1cm4gdHJ1ZTsKKworICAgIC8vIEZh bGwgYmFjayB0byBjb3B5aW5nIGFuZCB0aGVuIGRlbGV0aW5nIHNvdXJjZSBhcyByZW5hbWUoKSBk b2VzIG5vdCB3b3JrIGFjcm9zcyB2b2x1bWVzLgorICAgIGVjID0geyB9OworICAgIHN0ZDo6Zmls ZXN5c3RlbTo6Y29weShmc09sZFBhdGgsIGZzTmV3UGF0aCwgc3RkOjpmaWxlc3lzdGVtOjpjb3B5 X29wdGlvbnM6Om92ZXJ3cml0ZV9leGlzdGluZyB8IHN0ZDo6ZmlsZXN5c3RlbTo6Y29weV9vcHRp b25zOjpyZWN1cnNpdmUsIGVjKTsKKyAgICBpZiAoZWMpCisgICAgICAgIHJldHVybiBmYWxzZTsK KyAgICByZXR1cm4gc3RkOjpmaWxlc3lzdGVtOjpyZW1vdmVfYWxsKGZzT2xkUGF0aCwgZWMpOwog fQogCiBib29sIGdldEZpbGVTaXplKGNvbnN0IFN0cmluZyYgcGF0aCwgbG9uZyBsb25nJiByZXN1 bHQpCmRpZmYgLS1naXQgYS9Ub29scy9DaGFuZ2VMb2cgYi9Ub29scy9DaGFuZ2VMb2cKaW5kZXgg ZmExNjNlMzY3M2I0OWJkZTYwNjA2NTllMTk5YTVmMzlkYjBlYzU0ZS4uNTdhYWMzMDQ5Mzc2ZTVj MWUwMmJhN2E4Y2MwNjk3Y2E3ZDdhOWIzNCAxMDA2NDQKLS0tIGEvVG9vbHMvQ2hhbmdlTG9nCisr KyBiL1Rvb2xzL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE2IEBACisyMDIxLTA1LTAzICBDaHJpcyBE dW1leiAgPGNkdW1lekBhcHBsZS5jb20+CisKKyAgICAgICAgUmVzdG9yZSBwcmUtcjI3Njg3OSBi ZWhhdmlvciBmb3IgRmlsZVN5c3RlbTo6bW92ZUZpbGUoKQorICAgICAgICBodHRwczovL2J1Z3Mu d2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjI1MzA3CisKKyAgICAgICAgUmV2aWV3ZWQgYnkg Tk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgQWRkIEFQSSB0ZXN0IHRvIG1ha2Ugc3VyZSB0aGF0 IEZpbGVTeXN0ZW06Om1vdmVGaWxlKCkgaXMgYWJsZSB0byBtb3ZlIGRpcmVjdG9yaWVzIHNpbmNl IHRoaXMKKyAgICAgICAgd2FzIHRoZSBjYXNlIHByaW9yIHRvIHIyNzY4NzkuCisKKyAgICAgICAg KiBUZXN0V2ViS2l0QVBJL1Rlc3RzL1dURi9GaWxlU3lzdGVtLmNwcDoKKyAgICAgICAgKFRlc3RX ZWJLaXRBUEk6OlRFU1RfRik6CisKIDIwMjEtMDUtMDMgIFRpbSBOZ3V5ZW4gIDxudGltQGFwcGxl LmNvbT4KIAogICAgICAgICBBZGQgY29tbWl0dGVyIHN0YXR1cyBmb3IgIlRpbSBOZ3V5ZW4iIGlu IGNvbnRyaWJ1dG9ycy5qc29uCmRpZmYgLS1naXQgYS9Ub29scy9UZXN0V2ViS2l0QVBJL1Rlc3Rz L1dURi9GaWxlU3lzdGVtLmNwcCBiL1Rvb2xzL1Rlc3RXZWJLaXRBUEkvVGVzdHMvV1RGL0ZpbGVT eXN0ZW0uY3BwCmluZGV4IDBlY2RhOWI5ZTY2OGEyZGIwMGVhZTY5NDAyYTU0MjU2Y2JhMjI5NTgu LjhiNzNhZjFlODhkYWYyYmJlZGU2MjkzNmJhYzg3ZmMyZTRkODY4OGMgMTAwNjQ0Ci0tLSBhL1Rv b2xzL1Rlc3RXZWJLaXRBUEkvVGVzdHMvV1RGL0ZpbGVTeXN0ZW0uY3BwCisrKyBiL1Rvb2xzL1Rl c3RXZWJLaXRBUEkvVGVzdHMvV1RGL0ZpbGVTeXN0ZW0uY3BwCkBAIC0zMjgsNiArMzI4LDMyIEBA IFRFU1RfRihGaWxlU3lzdGVtVGVzdCwgbW92ZUZpbGVPdmVyd3JpdGVzRGVzdGluYXRpb24pCiAg ICAgRVhQRUNUX0dUKGZpbGVTaXplLCAwKTsKIH0KIAorVEVTVF9GKEZpbGVTeXN0ZW1UZXN0LCBt b3ZlRGlyZWN0b3J5KQoreworICAgIEZpbGVTeXN0ZW06OlBsYXRmb3JtRmlsZUhhbmRsZSB0ZW1w b3JhcnlGaWxlOworICAgIGF1dG8gdGVtcG9yYXJ5VGVzdEZvbGRlciA9IEZpbGVTeXN0ZW06Om9w ZW5UZW1wb3JhcnlGaWxlKCJtb3ZlRGlyZWN0b3J5VGVzdCIsIHRlbXBvcmFyeUZpbGUpOworICAg IEZpbGVTeXN0ZW06OmNsb3NlRmlsZSh0ZW1wb3JhcnlGaWxlKTsKKworICAgIEVYUEVDVF9UUlVF KEZpbGVTeXN0ZW06OmRlbGV0ZUZpbGUodGVtcG9yYXJ5VGVzdEZvbGRlcikpOworICAgIEVYUEVD VF9UUlVFKEZpbGVTeXN0ZW06Om1ha2VBbGxEaXJlY3Rvcmllcyh0ZW1wb3JhcnlUZXN0Rm9sZGVy KSk7CisgICAgYXV0byB0ZXN0RmlsZVBhdGggPSBGaWxlU3lzdGVtOjpwYXRoQnlBcHBlbmRpbmdD b21wb25lbnQodGVtcG9yYXJ5VGVzdEZvbGRlciwgInRlc3RGaWxlIik7CisgICAgYXV0byBmaWxl SGFuZGxlID0gRmlsZVN5c3RlbTo6b3BlbkZpbGUodGVzdEZpbGVQYXRoLCBGaWxlU3lzdGVtOjpG aWxlT3Blbk1vZGU6OldyaXRlKTsKKyAgICBGaWxlU3lzdGVtOjp3cml0ZVRvRmlsZShmaWxlSGFu ZGxlLCBGaWxlU3lzdGVtVGVzdERhdGEsIHN0cmxlbihGaWxlU3lzdGVtVGVzdERhdGEpKTsKKyAg ICBGaWxlU3lzdGVtOjpjbG9zZUZpbGUoZmlsZUhhbmRsZSk7CisKKyAgICBFWFBFQ1RfVFJVRShG aWxlU3lzdGVtOjpmaWxlRXhpc3RzKHRlc3RGaWxlUGF0aCkpOworCisgICAgYXV0byBkZXN0aW5h dGlvblBhdGggPSBGaWxlU3lzdGVtOjpwYXRoQnlBcHBlbmRpbmdDb21wb25lbnQodGVtcEVtcHR5 Rm9sZGVyUGF0aCgpLCAibW92ZURpcmVjdG9yeVRlc3QiKTsKKyAgICBFWFBFQ1RfVFJVRShGaWxl U3lzdGVtOjptb3ZlRmlsZSh0ZW1wb3JhcnlUZXN0Rm9sZGVyLCBkZXN0aW5hdGlvblBhdGgpKTsK KyAgICBFWFBFQ1RfRkFMU0UoRmlsZVN5c3RlbTo6ZmlsZUV4aXN0cyh0ZW1wb3JhcnlUZXN0Rm9s ZGVyKSk7CisgICAgRVhQRUNUX0ZBTFNFKEZpbGVTeXN0ZW06OmZpbGVFeGlzdHModGVzdEZpbGVQ YXRoKSk7CisgICAgRVhQRUNUX1RSVUUoRmlsZVN5c3RlbTo6ZmlsZUV4aXN0cyhkZXN0aW5hdGlv blBhdGgpKTsKKyAgICBFWFBFQ1RfVFJVRShGaWxlU3lzdGVtOjpmaWxlRXhpc3RzKEZpbGVTeXN0 ZW06OnBhdGhCeUFwcGVuZGluZ0NvbXBvbmVudChkZXN0aW5hdGlvblBhdGgsICJ0ZXN0RmlsZSIp KSk7CisKKyAgICBFWFBFQ1RfRkFMU0UoRmlsZVN5c3RlbTo6ZGVsZXRlRW1wdHlEaXJlY3Rvcnko ZGVzdGluYXRpb25QYXRoKSk7CisgICAgRVhQRUNUX1RSVUUoRmlsZVN5c3RlbTo6ZmlsZUV4aXN0 cyhkZXN0aW5hdGlvblBhdGgpKTsKK30KKwogVEVTVF9GKEZpbGVTeXN0ZW1UZXN0LCBnZXRGaWxl U2l6ZSkKIHsKICAgICBFWFBFQ1RfVFJVRShGaWxlU3lzdGVtOjpmaWxlRXhpc3RzKHRlbXBGaWxl UGF0aCgpKSk7Cg==