[Downloads] Retry renames after transient failures.

tools/metrics/histograms/histograms.xml

Index: tools/metrics/histograms/histograms.xml
diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml
index 4b53b1c08636d4395a798a041d25cbb88247fc5d..e093e173995561a138e499ac7fbb004843448f78 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -4630,6 +4630,15 @@ Therefore, the affected-histogram name has to have at least one dot in it.
   </summary>
 </histogram>
 
+<histogram name="Download.MapWinShErrorTransientError"
+    enum="SpecialShFileOperationCodes">
+  <owner>asanka@chromium.org</owner>
+  <summary>
+    Windows error that produced a DOWNLOAD_INTERRUPT_REASON_FILE_TRANSIENT_ERROR
+    result in MapShFileOperationCodes().
+  </summary>
+</histogram>
+
 <histogram name="Download.OnChanged">
   <owner>asanka@chromium.org</owner>
   <summary>
@@ -4763,6 +4772,24 @@ Therefore, the affected-histogram name has to have at least one dot in it.
   <summary>Time between the start of a download and its completion.</summary>
 </histogram>
 
+<histogram name="Download.TimeToRenameFailureAfterInitialFailure"
+    units="milliseconds">
+  <owner>asanka@chromium.org</owner>
+  <summary>
+    Time elapsed until a retried download file rename operation failed for the
+    last time after the initial rename failed.

[Randy Smith (Not in Mondays), 2014/06/11 18:07:29]

The code doesn't look like it's correctly implemented "for the last time"; the
recording function is executed (IIUC) after each rename failure, and it doesn't
have any conditionals that avoid this UMA except for success.

[asanka, 2014/06/12 20:02:38]

Hmm. We are reading the code differently. Doublecheck?

The histogram is recorded whenever we decide not to retry a rename anymore
(retries exit early before the UMA). At that point the rename operation has
either succeeded or failed, which is what this metric is recording.

The purpose of this pair of UMA is to keep tabs on whether we are waiting a
sufficient amount of time for the retry to succeed. I'm recording time so that
adjustments to the timing wouldn't require a new UMA. We'll just get spikes at
different points in the same histogram.

[Randy Smith (Not in Mondays), 2014/06/12 22:10:30]

Ah!!  Sorry, that's the point I was missing.  With that, everything makes sense.

+  </summary>
+</histogram>
+
+<histogram name="Download.TimeToRenameSuccessAfterInitialFailure"
+    units="milliseconds">
+  <owner>asanka@chromium.org</owner>
+  <summary>
+    Time elapsed until a retried download file rename operation succeeded after
+    the initial rename failed.
+  </summary>
+</histogram>
+
 <histogram name="Download.UserDiscard" enum="DownloadItem.DangerType">
   <owner>asanka@chromium.org</owner>
   <owner>felt@chromium.org</owner>
@@ -42562,7 +42589,9 @@ Therefore, the affected-histogram name has to have at least one dot in it.
 
 <enum name="SpecialShFileOperationCodes" type="int">
   <summary>Legacy error codes still returned by |ShFileOperation()|</summary>
-  <int value="5" label="Access denied"/>
+  <int value="5" label="Access denied (Win32)"/>
+  <int value="32" label="Sharing violation (Win32)"/>
+  <int value="87" label="Invalid parameter (Win32)"/>
   <int value="113" label="Source and Destination are same file"/>
   <int value="114" label="Multiple source mapped to single destination"/>
   <int value="115" label="Rename to different directory"/>