[physfs] request for 'openReadWrite'
Ryan C. Gordon
icculus at icculus.org
Sun May 3 19:00:35 EDT 2009
> 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
More information about the physfs