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.

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.

we would need to upload bits to blobber, probably on try server would be the best route to do this.

mainthread_io.log (raw): http://mozilla-releng-blobs.s3.amazonaws.com/blobs/Try-Non-PGO/sha512/8ccf0d1fb00fd3842c9038c6c195349c220e96dc81277d77f5da269eab823a27fd398ae42cfc743e5dd6f98fe8caa32d55f83bce905dc7756e0a3f31b8f3c247 mainthread_io.json (parsed): http://mozilla-releng-blobs.s3.amazonaws.com/blobs/Try-Non-PGO/sha512/26cb7db60deb479ad2bd43fd27c4fdb12bd5ea0abc9e06fa2c44b78fb55b577a84fcfee260fef2d86cf15ab3d215b6964ed943931cf430fc208b83916d115736 this is from the last 'x' in: https://tbpl.mozilla.org/?tree=Try&rev=26787ab34b9b

Comment on attachment 8520100 [details] [diff] [review] NtPathToDosPath should always produce long filenames Sending to Nathan since Ehsan is away.

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...

Added success check.

Whoops, something slipped in there. This one is right.

WTF!

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? ;)