John McMullen reports that PR_Seek on other platforms actually allows an offset past the end of file. PR_Seek on macintosh should be made to work the same way.

Reassigned the bug to gordon.

Changed target milestone to M4. I thought this was fixed already?

Don, pink fixed the only one known place (in the registry code) where this was called with the win/unix assumption. The real fix is to make the win/unix assumption valid always in future. Pink's fix was to write out enough bogus data to make the seek work.

And i'm sure that I'm writing out random bits of memory to disk, so there are certain privacy issues involved in that ;)

Note that while PR_Seek on Unix/Win platforms allows setting the file pointer beyond the current end of file, the file size itself is not changed by the seek operation. The next PR_Write call causes the write to happen at the new pointer; the data between the original end-of-file position and the position of the file pointer after PR_Seek is zero-filled by the OS. That is, if PR_Seek is used to seek beyond the end-of-file and the file is closed, there will be no change to the contents of the file (or the file size) on Unix/win platforms. To emulate the same semantics on Mac, one can save the file pointer in nspr's fd and extend the file on the next call to PR_Write. Also, file extension should be done with zero-filled pages, rather than random data.

Changed target milestone to M6.

Offloading some of gordon's doomage

NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.

Fix checked in. The old code would actually re-set the EOF on a seek past the current EOF but did not advance the file mark after resetting EOF.

this fix is not visible to qa. if you think this bug should be reopened, please do so. will mark as verified.