With 3/22 and later Firefox nightly builds, downloaded executable files appear to be truncated. Downloading the file a second time seems to work.

Backing out the fix for bug 162361 fixes this regression.

I downloaded two corrupted zip-files today but now I know why.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060323 Firefox/1.6a1 ID:2006032309 [cairo] confirmed. most downloads are corrupt. the same files are fine when downloaded with Opera

If there's anything wrong with my patch, it must be |GetFileInfo| I ported to nsLocalFileWin.cpp from NSPR.

Perhaps I was wrong. It's more likely to be |OpenFile| [1] which doesn't have the following part ported from NSPR: if (osflags & PR_CREATE_FILE) { if (_PR_NT_MakeSecurityDescriptorACL(mode, fileAccessTable, &pSD, &pACL) == PR_SUCCESS) { sa.nLength = sizeof(sa); sa.lpSecurityDescriptor = pSD; sa.bInheritHandle = FALSE; lpSA = &sa; } } BTW, I wasn't able to reproduce the problem with my build on Win2k, but it's reproducable on Win 2003 with the latest trunk build obtained from mozilla.org. [1] http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileWin.cpp#360

*** Bug 331639 has been marked as a duplicate of this bug. ***

This should fix the problem, but it can't be compiled because I can't export 'nsprpub/pr/include/private/primpl.h' that is necessary for PRFileDescPrivate. Adding it to RELEASE_HEADERS of Makefile.in somehow didn't work. So, I manually installed it, but then it requires md/osd...h What this patch does is to set Append mode manually as Win API doesn't have it. (see the definition of PRFileDescPrivate in nsprpub/pr/include/private/primpl.h). One way to solve this dillemma is to add |PR_ImportFileWithFlags(PROsfd osfd, PRIntn flags)|. |flags| will be ignored on platforms where APPEND is supported while it'll be used the same as it's used in |PR_Open| on platforms where APPEND is not supported.

(In reply to comment #5) > Perhaps I was wrong. It's more likely to be |OpenFile| [1] which doesn't have > the following part ported from NSPR: This is irrelevant. |PR_Open| in NSPR doesn't do it either. It's |_MD_PR_OPEN_FILE| (not |_MD_PR_OPEN|) that does it. BTW, for a mysterious reason, if I replace |(*fd)->secret->appendMode| with |fd->secret->appendMode| in the following part of attachment 216196 [details] [diff] [review], the source code can get compiled. Moreover, the binary obtained works correctly (no more truncation). + if (*fd) { + // On Windows, _PR_HAVE_O_APPEND is not defined so that we have to + // add it manually. (see |PR_Open| in nsprpub/pr/src/io/prfile.c) + (*fd)->secret->appendMode = (PR_APPEND & flags) ? PR_TRUE : PR_FALSE; return NS_OK; + }

I added |PR_ImportFileToAppend|. It's #defined as |PR_ImportFile| where O_APPEND is supported while it's a little wrapper over |PR_ImportFile| that sets appendMode in PR_FileDescPrivate elsewhere.

Darin, what do you think of this approach? wtc is out of town and won't be back until April 5(?)th...

Could this append stuff be the cause of bug 331665?

(In reply to comment #9) > Created an attachment (id=216212) [edit] > a better patch I can confirm that this patch fixes the proble.

jshin: If we're going to need another variant on PR_ImportFile, then I think it might make sense to call it PR_ImportFile2 and define a flags parameter as a second argument. That would allow us to extend the API further in the future if needed for other things like this. I'd really like to know WTC's thoughts on this.

*** Bug 331682 has been marked as a duplicate of this bug. ***

jshin: As a temporary workaround for this bug, you could copy the definition of PRFilePrivate into nsLocalFileWin.cpp. Then, when WTC gets back we can replace that with a new function exported by NSPR.

Asking for r/sr. As a temporary workaround, I copied the definition of PRFilePrivate to nsLocalFileWin as suggested by Darin. Along with it, two more have to be copied.

Comment on attachment 216268 [details] [diff] [review] patch with PRFilePrivate copied to nsLocalFileWin r+sr=darin (ok, please file the follow-up bug about fixing this the right way if you haven't already)

Thanks for r/sr. The patch landed on the trunk. I filed bug 331767 for fixing this issue the right way.