Possible problem with apr_file_dup() and apr_file_seek()?

[Frank Jas <fr...@jrware.com>]

Either I'm misusing apr_file_dup() and apr_file_seek() or there's a problem 
with the apr_file_t filePtr field (using APR version 1.3.3).

Here's the sequence:

    apr_file_open( f1, "myfile", APR_READ | APR_WRITE | APR_BUFFERED, ... );
    apr_file_dup( f2, f1 );

read the contents of the file using f2

    apr_file_truncate( f1, 0 );

write new contents into the file using f1.

The new contents appear starting at the byte offset equal to the original file 
size rather than at the beginning of the file.

What's happening is the apr_file_seek() performed in apr_file_truncate() 
doesn't actually call lseek() since its filePtr is still set to 0, eventhough 
the system file position has been moved to the end of the file due to the 
read using the duped file. This is because underlying file descriptors are 
duped and share the file offset information, so reads on one will affect the 
file position seen by the other.

Is this a bug or am I using these functions incorrectly? The rationale for the 
duped file is that I wanted to copy the file w/o buffering, so I duped the 
file and turned off buffering using apr_file_buffer_set().

Frank