[release/6.0] Update zip extraction to never throw any exceptions when the LastWriteTime update fails

[github-actions]

Backport of #63912 to release/6.0

/cc @adamsitnik@EatonZ

Customer Impact

After successful extraction to a file, the file handle is closed. After that, it's opened again to set the last write time. As reported by customer in #63912 some AV software can open it in the meantime and lock the access to the file. As the end result, Windows customers, who have AV software installed can sporadically observe an IOException (ERROR_SHARING_VIOLATION).

Testing

I was not able to reproduce this bug locally and I don't think that it's possible to implement a reliable test for it.

Risk

Can't see any.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #63912 to release/6.0

/cc @adamsitnik@EatonZ

Customer Impact

Testing

Risk

Author:	github-actions[bot]
Assignees:	-
Labels:	area-System.IO.Compression
Milestone:	-

[EatonZ]

I appreciated the approval for a servicing release.👍
When do you think 6.0.3 will release?

[danmoseley]

When do you think 6.0.3 will release?

Scheduled for 2nd week of March.

[safern]

Failures are unrelated. System.Text.Json failure is: #61524

Diagnostics failure seems to be a machine in a bad state:

System.InvalidOperationException : Cannot load Counter Name data because an invalid index '' was read from the registry. Performance counters on the machine may need to be repaired.