User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20171005074949 Steps to reproduce: Sent an email that had a .tar.gz file (produced by R) as an attachment to myself or another user @ucsf.edu. It is hosted at office365.com. Use firefox to log in to outlook for the web (OWA), find the message. The file shows as the correct size, 211KB. Click on the attachment and select download. Possibly related bugs: 610679 (refers specifically to double compression), 714805, 233407, 902503, 1269101, Actual results: The resulting downloaded file is 325KB, and is corrupt as far as R i or tar is concerned. Inspecting the file with unix file (in cygwin) says it is a gz file with lowest compression/highest speed. gunzip produces a file named xxx.tar, but file shows this as a gz file with maximum compression. I'm not sure if it's identical to the original attachment, but it is about the right length. If renamed to end .tar.gz the resulting file is useable. So the file that ends up on my disk is my original file with a second layer of gzip compression on top of it. The second layer of "compression", apart from making the file uninterpretable, makes it ~ 50% larger. Expected results: The file in the attachment, my original file, should have ended up on my disk. The correct behavior happens with either MS IE or Chrome. I have tried this on multiple physical systems, multiple versions of Windows (7 and 2012 R2), and multiple versions of FF (32 bit ESR or 64 bit current)--probably also multiple versions of the other browsers too. All systems are running 64 bit windows. I think I've seen the same problem with FF on Debian GNU/Linux 64 bit, but am not 100% sure. And, since the original problem happened when I sent the file to someone else, it's been tested under a different user (who used FF on Win7). A campus tech support person experienced the same problem with the same file--so at least 3 people experience the same problem. I do not know what protocols are being used when I hit download for the file attachment.
On the protocols used, I did the download again with the console open. It shows GET https://outlook.office.com/owa/service.svc/s/GetFileAttachment and the response headers include Cache-Control private Content-Dispositionattachment; filename*=UTF-8''LazarSim_0.9-1.tar.gz Content-Encoding gzip Content-Type application/gzip; authoritative=true; ... Strict-Transport-Security max-age=31536000; includeSubDomains Vary Accept-Encoding X-BEServer BY2PZ05MB1957 X-BackEnd-Begin 2017-11-04T01:30:48.056 X-BackEnd-End 2017-11-04T01:30:48.259 X-BackEndHttpStatus 200 X-CalculatedBETarget BYZPR05MB1957.namprd05.prod.outlook.com X-Content-Type-Options nosniff X-DiagInfo BZ2PR05MB1957 X-FEServer BZ2PR02CA0123 X-Firefox-Spdy h2 X-Frame-Options SAMEORIGIN X-OWA-Version 220.127.116.11 X-UA-Compatible IE=EmulateIE7 I've omitted other info that looked either irrelevant or possibly security-exposing. P.S. I would be nice if I could copy and paste from the log without having to manually restore the formatting.
Hi Ross, I don't have a office 365 hosted mail account (so I use outlook.live.com instead), sending an email from gmail. The mail includes an attachment, a tarball created by command |tar -czvf foo.tar.gz bar.txt|. Then I download the file and check the SHA256 digest. It shows the file and the original one are identical. We'd very like to fix this issue, so some more information is very helpful. Would you: - provide the log by following instructions on  - see if you can reproduce this on public systems, so we can look into this more easily. Thanks.  https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging