Closed Bug 1090389 Opened 10 years ago Closed 10 years ago

fix mainthread IO logging code to expand user path when logging events

Categories

(Core :: XPCOM, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jmaher, Assigned: bugzilla)

References

Details

Attachments

(1 file, 3 obsolete files)

right now in talos we are comparing our mainthead IO log to a whitelist and turning a job orange when it doesn't match.

We have a scenario where on windows the profile is in c:\\users\\cltblduser, but sometimes we get files with a long path and a short path:
c:\\users\\cltblduser
c:\\users\\cltbld~1
c:\\users\\cltbld~1.t-w (on 3 machines)

If we had the path expanded for all logged events, we wouldn't have to programatically hack the mainthread IO/whitelist code in talos to guess at these permutations.
Blocks: 1081354
Do we have any of the original, raw log output from Firefox for these cases? If no, how hard would it be to obtain one?

I suspect that I need to add code to the IOInterposer logger to normalize the file paths, but I'd like to confirm that.
Flags: needinfo?(jmaher)
we would need to upload bits to blobber, probably on try server would be the best route to do this.
Assignee: nobody → aklotz
Status: NEW → ASSIGNED
Comment on attachment 8520100 [details] [diff] [review]
NtPathToDosPath should always produce long filenames

Sending to Nathan since Ehsan is away.
Attachment #8520100 - Flags: review?(ehsan.akhgari) → review?(nfroyd)
Comment on attachment 8520100 [details] [diff] [review]
NtPathToDosPath should always produce long filenames

Review of attachment 8520100 [details] [diff] [review]:
-----------------------------------------------------------------

::: xpcom/io/FileUtilsWin.h
@@ +20,5 @@
> +  auto inputPath = PromiseFlatString(aDosPath);
> +  // Get the required length of the long path name
> +  DWORD longPathLen = GetLongPathNameW(inputPath.get(),
> +                                       aDosPath.BeginWriting(),
> +                                       aDosPath.Length());

As discussed on IRC, this call needs to check to see if it succeeded, otherwise, the rest of the function isn't going to work right (particularly the check at the end).

Though presumably the test bit that you changed works as-is right now, and doesn't require any expansion to long paths, so I'm not quite sure what's going on...
Attachment #8520100 - Flags: review?(nfroyd) → feedback+
Added success check.
Attachment #8520100 - Attachment is obsolete: true
Attachment #8521571 - Flags: review?(nfroyd)
Whoops, something slipped in there. This one is right.
Attachment #8521571 - Attachment is obsolete: true
Attachment #8521571 - Flags: review?(nfroyd)
Attachment #8521573 - Flags: review?(nfroyd)
WTF!
Attachment #8521573 - Attachment is obsolete: true
Attachment #8521573 - Flags: review?(nfroyd)
Attachment #8521575 - Flags: review?(nfroyd)
Comment on attachment 8521575 [details] [diff] [review]
NtPathToDosPath should always produce long filenames (rev. 2)

Review of attachment 8521575 [details] [diff] [review]:
-----------------------------------------------------------------

Is that your *final* patch, Aaron? ;)
Attachment #8521575 - Flags: review?(nfroyd) → review+
https://hg.mozilla.org/mozilla-central/rev/5513bdd6a5ac
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 36
Component: General → XPCOM
Product: Firefox → Core
Target Milestone: Firefox 36 → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: