[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).
>

Yeah exactly. The app developer would need to be careful with that, and
do some extra work to ensure the write directory gets the highest
priority from reading. Something the library could easily provide.

>> 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 memory use is really a concern in one of my target platforms, the
nintendo wii. It has only 32mb of ram. But what I'm really concerned
about is data safety. The user would be really mad if he lost his saves
because of power failure or application crash. To overcome this, I would
need to write the whole file back to permanent storage periodically. And
the wii uses flash memory for that, which is slow, and would suffer very
accelerated tear from the constant writing.

I'm not interested in buffering at all. I was just making a
point in the best interest of the library.

>> 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.

Would you mind elaborating on those dangers?
Also, currently, append mode already ignores the file existing in the
read path. If we want to implement the semantic I proposed, this would
need to be done for append too, for consistency.
But if we really want to leave append this way, then the even simpler
semantic already implemented in my patch is good enough.

> --ryan.
>
> _______________________________________________
> physfs mailing list
> physfs at icculus.org
> http://icculus.org/mailman/listinfo/physfs