[physfs] request for 'openReadWrite'

[Matheus Izvekov]

On 16:00 Sun 03 May     , Ryan C. Gordon wrote:
>
>> 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.

So how do we stand on this? Given any thought?
Maybe we could go on an even simpler approach, and just allow reading for files
opened for writing/appending. Are there any programs that depend on read failing
on those files?