You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I contribute to the LÖVE game framework, which uses PhysFS, and a common user complaint has been that while the write-to-single-common-directory paradigm works OK for most games, it's too limited for things like tools and non-standard games or other apps that need to interact with the filesystem in more arbitrary manners.
Another related issue is that many operating systems (e.g. macOS, iOS, Windows) really want apps to use different common data locations for slightly different purposes. For example on iOS, files saved to Documents and Application Support may be automatically cloud-synced whereas files saved to tmp and Caches will not be. And Documents is meant for user-visible content (e.g. screenshots) whereas Application Support is not (e.g. a progress save file). Since iOS has restrictive sandboxing, I don't believe setting / as the write directory works.
In my opinion having to change the write directory - and having to make sure all open-for-write files are closed before doing so - each time a file is written to a different one of those locations is much too cumbersome and limiting, and doesn't fit with PhysFS' other virtual filesystem APIs.
To lift those limitations in LÖVE, I forked PhysFS and added a new PHYSFS_mountRW function which is just like PHYSFS_mount but with some internals changed to allow writing to the given location. Since write access tends to be allowed in fewer locations than read access, having a separate function from PHYSFS_mount still makes a lot of sense to me (although I suppose an enum or boolean parameter would work too, but it would also be a breaking change).
Here is my branch with the change: main...slime73:mountRW It's been tested but not by a ton of people yet, and I don't have a ton of experience with PhysFS' codebase so there might be bugs.
My questions are: is the overall idea within the scope of what you want PhysFS to be, and if so is my API reasonable? If yes I can open a pull request. I don't mind maintaining a fork but I'd prefer having the idea upstreamed.
The text was updated successfully, but these errors were encountered:
I'll have to look at this more closely, which I can't right now, but I would like to do something like this, if we don't do this exact thing, so I'm going to let this issue float open for a little bit.
I contribute to the LÖVE game framework, which uses PhysFS, and a common user complaint has been that while the write-to-single-common-directory paradigm works OK for most games, it's too limited for things like tools and non-standard games or other apps that need to interact with the filesystem in more arbitrary manners.
Another related issue is that many operating systems (e.g. macOS, iOS, Windows) really want apps to use different common data locations for slightly different purposes. For example on iOS, files saved to
Documents
andApplication Support
may be automatically cloud-synced whereas files saved totmp
andCaches
will not be. AndDocuments
is meant for user-visible content (e.g. screenshots) whereasApplication Support
is not (e.g. a progress save file). Since iOS has restrictive sandboxing, I don't believe setting/
as the write directory works.In my opinion having to change the write directory - and having to make sure all open-for-write files are closed before doing so - each time a file is written to a different one of those locations is much too cumbersome and limiting, and doesn't fit with PhysFS' other virtual filesystem APIs.
To lift those limitations in LÖVE, I forked PhysFS and added a new
PHYSFS_mountRW
function which is just likePHYSFS_mount
but with some internals changed to allow writing to the given location. Since write access tends to be allowed in fewer locations than read access, having a separate function fromPHYSFS_mount
still makes a lot of sense to me (although I suppose an enum or boolean parameter would work too, but it would also be a breaking change).Here is my branch with the change: main...slime73:mountRW It's been tested but not by a ton of people yet, and I don't have a ton of experience with PhysFS' codebase so there might be bugs.
My questions are: is the overall idea within the scope of what you want PhysFS to be, and if so is my API reasonable? If yes I can open a pull request. I don't mind maintaining a fork but I'd prefer having the idea upstreamed.
The text was updated successfully, but these errors were encountered: