Hi. It looks like ERROR_ACCESS_DENIED when trying to move the version directory. Perhaps anti-virus software is interfering. Could you capture a log with Process Monitor (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx) and share it with me (grt at chromium dot org)? Thanks for your help in investigating this.

No feedback was received in the last 30 days from reporter "aeroriderkiller@gmail.com", so archiving this. Please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hi,I got the log now,sorry for not reply soon, as I can't make it reappear.
here is chrome_install.log,and the ProcMon log in attatchment
[0915/170536:ERROR:move_tree_work_item.cc(94)] failed move C:\Program Files
(x86)\Google\Chrome\Temp\source8504_15634\Chrome-bin\53.0.2785.113 to
C:\Program Files (x86)\Google\Chrome\Application\53.0.2785.113: 拒绝访问。 (0x5)
[0915/170536:ERROR:work_item_list.cc(48)] item execution failed
[0915/170536:ERROR:work_item_list.cc(57)] Failed execution of work item
list
[0915/170536:ERROR:install.cc(220)] Install failed, rolling back... result:
7
[0915/170539:ERROR:install.cc(222)] Rollback complete.
[0915/170539:ERROR:installation_validator.cc(490)] Google Chrome has a
usagestats value (0), yet should not.
[0915/170539:ERROR:setup_main.cc(1863)]

Indeed, access denied when moving ...\Temp\source8504_15634\Chrome-bin\53.0.2785.113 to Application\53.0.2785.113:

11:05:36.5848623 AM	setup.exe	8504	SetRenameInformationFile	C:\Program Files (x86)\Google\Chrome\Temp\source8504_15634\Chrome-bin\53.0.2785.113	ACCESS DENIED	ReplaceIfExists: True, FileName: C:\Program Files (x86)\Google\Chrome\Application\53.0.2785.113

Now the question is what is it that is interfering with move? Could you check:
- does the directory "C:\Program Files (x86)\Google\Chrome\Application\53.0.2785.113" already exist?
- if you look at the full procmon log, do you see that another process is accessing either "C:\Program Files (x86)\Google\Chrome\Application\53.0.2785.113" or "C:\Program Files (x86)\Google\Chrome\Temp\source8504_15634\Chrome-bin\53.0.2785.113"?

Thank you for your help.

 Issue 587849  has been merged into this issue.

We have another case of this. Hopefully we can repro to understand what's really going on.

Do any impacted users have a McAfee A/V product installed? If so, temporarily disable real-time scanning and then try installing Chrome (remember to re-enable scanning if you wish). Please respond on this issue if you try this and it helps. Thanks.

After spending a lot of time looking at logs, here are some things we could do to make Chrome's installer more robust in the face of scanners:

- file_util_win.cc calls RemoveDirectory in two places when doing a recursive directory delete. In both cases, the contents of the directory being deleted have already been deleted. I believe it's possible for these calls to fail with ERROR_DIR_NOT_EMPTY if the kernel and/or drivers have yet to fully process the file deletes. We could add a retry with a very short delay to these in the expectation that they would soon succeed.

- move_tree_work_item.cc expects base::Move to be atomic. It isn't. In the cases I examined, base::Move had copied the source to the dest, deleted all files in the source, then failed to delete the source directory itself (see above). If MoveTreeWorkItem had only known this, it could have allowed the install to continue with the knowledge that the source dir would eventually be cleaned up. It doesn't have that knowledge. It would probably be wise to re-implement MoveTreeWorkitem in terms of MoveFileEx and a copy-n-delete fallback manually so that it can proceed when appropriate and rollback properly.

- Ultimately, it would be good to change the way the installer works at a higher level so that it extracts the version directory straight into the target dir rather than into a Temp dir and then moving it. This will avoid the problem of concurrent A/V scans altogether. This will be a much larger project with implications around how to handle overinstalls (same version repair) and partial installs/updates (interrupted by crash or tripping over the power cord).

I'm working on making MoveTreeWorkItem more robust. This should help a lot.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/51ebae1b6ce29d6ba3245e651032a110903cd499

commit 51ebae1b6ce29d6ba3245e651032a110903cd499
Author: Greg Thompson <grt@chromium.org>
Date: Tue May 08 17:43:16 2018

Record metrics when base::DeleteFile fails on Windows.

This CL logs the Windows.PostOperationState.DeleteFile.* and
Windows.FileSystemError.DeleteFile.* histograms to shed some light on
when and why deletes fail on Windows. These will help inform subsequent
changes to our delete strategy to be sure that we don't make things
worse.

BUG=599084

Change-Id: Ieefdd6a98a7d6636f7cfb2cffd4685e32bf00283
Reviewed-on: https://chromium-review.googlesource.com/1044193
Commit-Queue: Greg Thompson <grt@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Jesse Doherty <jwd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556859}
[modify] https://crrev.com/51ebae1b6ce29d6ba3245e651032a110903cd499/base/files/file_util_win.cc
[modify] https://crrev.com/51ebae1b6ce29d6ba3245e651032a110903cd499/tools/metrics/histograms/enums.xml
[modify] https://crrev.com/51ebae1b6ce29d6ba3245e651032a110903cd499/tools/metrics/histograms/histograms.xml

Interesting. 15% of recursive delete failures report that a thing to be deleted doesn't exist. That ain't right. I wonder if we can bring up the success rate by fixing something there.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9278098718db1ba85c526bd51e512e93d06cca09

commit 9278098718db1ba85c526bd51e512e93d06cca09
Author: Greg Thompson <grt@chromium.org>
Date: Thu May 24 18:20:39 2018

Treat "file not found" the same as "success!" in all cases while deleting.

Instrumentation added in r556859 revealed that some deletes are failing
because the thing-to-be-deleted isn't there. This here CL attempts to
plug all holes in the delete logic so that this is treated as a
condition for success.

BUG=599084
R=gab@chromium.org

Change-Id: I04e2c22ac49bc0bd7b7850b2d17abc72f3e05e7b
Reviewed-on: https://chromium-review.googlesource.com/1071656
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#561553}
[modify] https://crrev.com/9278098718db1ba85c526bd51e512e93d06cca09/base/files/file_util_win.cc