[physfs] request for 'openReadWrite'

Matheus Izvekov mizvekov at gmail.com
Fri May 1 22:42:37 EDT 2009


On 18:42 Fri 01 May     , Ryan C. Gordon wrote:
>
>> Is this addition compatible with the scope of the aforementioned library?
>
> Is the problem that there's no read+write call, or is the problem that  
> writing options are either truncate or append?

It's that there is no read+write call. My application has several fs
usage patterns, and two of them require reading in addition to writing.

> Is it not reasonable to open the same file twice, once for read and once  
> for write? Append mode will let you seek back, despite the name.
>

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

> I'd be hesitant to add an openReadWrite() call; it brings up all sorts  
> of questions about which file you should be actually be accessing, and  
> I'd rather dodge that question entirely.

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.

> Also, out of curiousity: what are you doing that requires you to read  
> and write the same file at the same time? I'm sure there are legitimate  
> use cases for that, I'm just curious.

One of the usage cases is the memory card file of an emulator. The game
can access it any way it wants, reading and writing to any location in any
order, and i have no control over that. There can be many memory cards
connected, and the file is not too small (128kb minimum) and it will be
used in memory constrained platforms. And the user wants this data
preserved in case of powerloss/crash. So keeping this file in memory and
writing it all in one go is not an option.

>
> --ryan.


More information about the physfs mailing list