[physfs] request for 'openReadWrite'

[Ryan C. Gordon]

> It could open the file 2 times, it would obviously be equivalent from a
> functionality point of view. But I though the library made no promises
> if you tried to open the same file twice. It would be worse this way,

The problem is that I can't make any promises about opening the file 
once in two modes, when one of the major concepts of the library is that 
reading and writing have a distinct barrier between them.

The only concern, from an app level, is making sure you get the same 
file for read and write: set your write path to the correct place, and 
make sure that directory gets highest priority in the search path 
(either add it to the search path in the right order, or use a mount 
point to put in somewhere unique).

> because then interaction with the library buffering would break things.
> You would not have any reasonable way to implement both reading and writing
> to the same file with buffering.

This is a good point. Perhaps we should allow an application to provide 
its own buffer for a given file handle, and make promises that the same 
buffer will safely work with multiple handles--read and write--so long 
as it's the same file underneath.

Note that we're unbuffered by default, so opening the same file for 
read/write will Just Work (and the OS will buffer anyhow, in most cases).

Also: you have a valid point, but if you're so memory-constrained that 
you can't store a 128k file in memory, I don't know why you'd turn 
buffering on at all.

> Well the semantic of copying the file from any of the readonly locations
> to the write dir and then starting from there would make perfect sense.

It does at the application level (and the existing API gives you the 
tools for this), but it's probably a dangerous design decision at the 
library level.

--ryan.