Spin-off of bug 331453. In bug 331453 comment #7, I wrote: > 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 the same bug, Darin also suggested doing this, but he really wanted to hear from wtc. Because he's out of town until April 5(?)th, we decided to fix bug 331453 in an ad-hoc manner with the understanding that it would be fixed in 'the right' way later. So, here am I filing this bug.

I thought all copied functions would have gone when bug 330665 is fixed. Is it really required just to be called from temporary functions? Please correct me if I'm wrong.

The right way to fix this problem is to add PR_OpenFileUTF16. Recall that the purpose of using CreateFileW and PR_ImportFile was to avoid being blocked by the availability of PR_OpenFileUTF16.

Darin, jshin: you should be able to use a PRFileDesc I/O layer to solve this problem. In this layer, we record whether the Windows file handle was opened with the PR_APPEND flag. This layer would forward all PR I/O methods but PR_Write to the lower layer. For PR_Write, this layer would seek to the end of file (similar to what FileWrite in mozilla/nsprpub/pr/src/io/prfile.c does) before invoking the write method of the lower layer if the PR_APPEND flag is set.