PR_Open() has a flag "PR_APPEND" which the document claims will open the file with the offset at the end of the file. This is not currently implemented on Win32.

Accepted the bug. Added larryh and srinivas to the cc list. Thanks for the bug report, Chris. We are aware of this bug. In fact, the PR_APPEND flag is also incorrectly implemented on the Mac. Right now this flag only works correctly on Unix.

Added dougt and mcmullen to the cc list. The correct behavior of PR_APPEND is to set the file pointer to the end of file prior to each write. I believe only Unix has native support of this behavior (the O_APPEND flag for open()). On other platforms this behavior needs to be emulated. The Mac implementation of PR_APPEND only sets the file pointer to the end of file when the file is opened. This is wrong and I am guilty (I thought that's how PR_APPEND should work). In most cases, this bug can be easily worked around. Open the file without the PR_APPEND flag, and call PR_Seek(fd, 0, PR_SEEK_END) to move the file pointer to the end of the file. As long as you don't move the file pointer again, it will stay at the end of file. In fact, this method will turn out to be more efficient on Win32 and Mac because to emulate PR_APPEND we have to move the file pointer prior to each write.

>The correct behavior of PR_APPEND is to >set the file pointer to the end of file >prior to each write. I believe only Unix >has native support of this behavior (the >O_APPEND flag for open()). On other >platforms this behavior needs to be >emulated. What? You mean if I open in append mode, and explicitly seek to the beginning of the file and then write again, it's going to scoot me back to the end? So seeking in a file opened in append mode is ignored and is a waste of time (except for reading)? I find this strange. An explicit seek-to-end on open (what you did implement) would be what I, too, expected.

Yes to all of your questions, John. This is the behavior of Unix's O_APPEND flag, after which PR_APPEND was modeled. After I realized this, I no longer think PR_APPEND is useful.

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

As fate would have it, David B. was asking me about this just 30 minutes ago. cc- ing him.

phillip gone, removing him from qa contact, sorry for spam

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

O_APPEND is useful for log files that may be written to by many processes. This requires any emulation to do the seek()/write() operations underneath a file lock.

Reassigned to larryh as a NSPR 4.1 task.

Checking in parts: cvs commit -m"BugZilla: 4090. PR_APPEND" pr/tests/append.c RCS file: /cvsroot/mozilla/nsprpub/pr/tests/append.c,v done Checking in pr/tests/append.c; /cvsroot/mozilla/nsprpub/pr/tests/append.c,v <-- append.c initial revision: 1.1 done cvs commit -m"BugZilla: 4090. PR_APPEND" pr/include/private/primpl.h Checking in pr/include/private/primpl.h; /cvsroot/mozilla/nsprpub/pr/include/private/primpl.h,v <-- primpl.h new revision: 3.50; previous revision: 3.49 done cvs commit -m"BugZilla: 4090. PR_APPEND" pr/src/io/prfile.c Checking in pr/src/io/prfile.c; /cvsroot/mozilla/nsprpub/pr/src/io/prfile.c,v <-- prfile.c new revision: 3.31; previous revision: 3.30 done cvs commit -m"BugZilla: 4090. PR_APPEND" pr/tests/Makefile Checking in pr/tests/Makefile; /cvsroot/mozilla/nsprpub/pr/tests/Makefile,v <-- Makefile new revision: 3.64; previous revision: 3.63 done

Marking as fixed.

This is what Larry checked in to the NSPR sources (minus the test program changes) when he marked this bug fixed.

This patch shows changes made to this code since Larry's original change.